The Consequential AI Evidence Monitor
What does the system prove, and who must be trusted to verify it?
Every AI control produces some record of what it did. The records differ in what they can establish and in who has to be believed. This page is a typology of those evidence models, without vendor names.
Monitor · Method · Transactions · Duties · What systems prove
Why a typology and not a product table
Product comparisons age fast and invite arguments about features. The durable question sits underneath: by construction, what evidence does this class of system produce, and who must be trusted before that evidence can be believed? Those properties follow from where the control sits and who holds the keys, so they can be described for a class without naming anyone.
Each class below is legitimate engineering that answers a real question. The typology describes what each one establishes; it does not rank them. To evaluate a specific product, apply the twelve questions at the end of this page to that vendor’s own published materials.
Six evidence models
1. Controls inside the generating system
Safety instructions, alignment layers and refusal behavior implemented within the model or its serving stack. The control and the system it controls run in the same place.
- Record produced
- The system’s own outputs and operator logs.
- Verified by
- The operator of the generating system. Controls implemented within the governed system can remain dependent on that system’s own behavior and execution environment.
- Establishes
- That the system was configured to behave a certain way, on the operator’s word.
2. Gateway and proxy logging
A routing point between applications and models: policy enforcement, rate limiting and logging of the traffic that passes through it.
- Record produced
- Operational logs of requests and responses, held by whoever runs the gateway.
- Verified by
- The gateway operator, and whoever administers the log store. A log’s integrity is a property of the store it lives in.
- Establishes
- What traffic passed the gateway, for readers with access to and trust in the log store.
3. Identity and access platforms
Credentials, sessions and entitlements for humans, machines and agents: who may connect to what.
- Record produced
- Access and session logs inside the platform.
- Verified by
- The platform and its administrators.
- Establishes
- Which identity held which entitlement at which time. The record generally attaches to the session or credential rather than to the content of a specific action.
4. Observability and evaluation
Measurement of deployed model behavior: dashboards, metrics, evaluations and alerts, examined after the behavior occurs.
- Record produced
- Aggregated metrics and traces in an analytics store.
- Verified by
- The team operating the observability stack.
- Establishes
- How the system behaved over time, as measured. Measurement observes an action; it is a different function from deciding whether the action may proceed.
5. Content provenance and credentials
Signed metadata that travels with a piece of content, recording how it was produced or edited.
- Record produced
- A credential embedded in or attached to the artifact, signed by the producing tool or service.
- Verified by
- Anyone with the artifact and the toolchain’s public keys. Signing keys are typically held by the tool or service vendor.
- Establishes
- The recorded production history of a piece of content. It speaks to the content’s origin rather than to whether any action was authorized.
6. External pre-action authority check with an independently verifiable record
A control that sits outside the governed system, evaluates a defined action against current human authority before the action proceeds, fails toward stop, and signs a record bound to the authority in force at that moment.
- Record produced
- A signed artifact per governed action, designed to leave the operator’s custody.
- Verified by
- Any holder of the record, with public code, offline, without contacting the operator or the vendor.
- Establishes
- That a named authority applied to the action before it proceeded, and that the record has not been altered since, checkable by an outsider.
Regulayer is one implementation of this class; the mechanism is described on the product pages and can be exercised on the live demos.
The twelve questions
To place any specific product in this typology, put these questions to the vendor’s own published materials. Where a property is not described there, the accurate note is “not located in reviewed public product materials”, with the review date. That is a statement about the materials, never a claim that the capability is absent.
- Does the record identify the acting agent?
- Does it identify the authenticated human behind the action?
- Does it record delegation, from whom to whom?
- Is policy evaluated before the action, or is the action examined afterward?
- Can authority be revoked, and does the system evaluate current authority rather than the authority that existed when the workflow began?
- Is each event signed?
- Who controls the signing key, the vendor or the customer?
- Does enforcement and evidence production operate without network egress?
- Can the record be verified outside the vendor’s systems?
- Is the record bound to the version of authority in force at the moment of the action?
- What happens on failure or silence: does the protected action proceed, or stop?
- Is there a public method by which an outsider can verify a record?
The boundary of this page. No vendor is named, no product is scored, and no class is declared inadequate. Different classes answer different questions, and many deployments run several at once. What a reader can take from the typology is the trust question itself: for the record your system produces, who has to be believed, and can anyone outside check?
Last reviewed 27 August 2026. Information, not legal advice.