EVIDE vs Execution Certification

A growing class of systems focuses on proving that an AI pipeline ran correctly: deterministic execution logs, reproducible outputs, runtime audit trails, behavioral proofs. These are valuable and necessary. They answer the question:

EVIDE answers a different question:

These are not competing answers. They address different evidentiary layers. Confusing them leads to governance gaps that become visible only under audit, litigation, or regulatory investigation.

Execution evidence is designed to make machine behavior examinable. An EVIDE deposit preserves a different object. Their typical focus:

Systems presented as "AI evidence" combine, in different ways, a small number of functions. Three are useful to name, because each answers a different question:

EVIDE operates at the declared closure boundary — the point at which a decision is declared closed and attributed to an authority. A deposit preserves three kinds of content: what was declared, what EVIDE recorded at intake, and signals computed from the declared payload.

• Declared: the authority to whom responsibility is attributed, with its declared role
• Declared: the intervention type and rationale at closure
• Declared: the classification state and its stated operational stability
• Declared: the upstream governance structure stated as active
• Declared: the threshold stated as met, not met, unknown or not defined
• Declared: the admissibility conditions stated at the closure point
• Declared: the human oversight level stated
• Declared: the attribution status of the threshold owner
• Declared: which gate assessed boundary stability, with its stated scope
• Declared: the gate's stated observational coverage — complete, partial or insufficient
• Declared: the signals stated as unresolved at the boundary crossing
• Recorded by EVIDE: the SHA-256 fingerprint of the canonical record, the intake time (UTC), the verified identity of the depositing account (DAPI) and the Evidentiary Artifact Record
• Computed from the payload: the evidentiary profile — 11 dimensions, profile_version 1.1 — whose states describe the declared record, not the operational reality behind it

When a decision is challenged externally — in audit, in court, in regulatory review — execution logs and declaration records answer different questions, and both can contribute to reconstructing what happened. The EVIDE deposit adds the declared responsibility record, held outside the originating system.

A system can continue executing — producing outputs, maintaining workflow stability, appearing structurally sound — while the responsibility coherence beneath that execution has already degraded at the moment the closure state was externalized.

Execution evidence alone may not surface this condition: execution validity and declared continuity are measured against different reference axes.

When the declared payload reflects this condition, the evidentiary profile exposes it through three inferred dimensions:

• Dim 9 — Continuity (Forensic Cross-Check): flags tension between the declared classification stability and the declared runtime visibility at crossing time. An execution-valid, continuity-degraded closure produces state: degraded — not stable. This is a deterministic server-side computation from declared payload fields: classification_status × runtime_visibility → continuity_state.
• Dim 10 — Decision Wave Compression (DWC): signals, from declared fields, an approach to the throughput boundary of meaningful oversight — decisions accumulating faster than the declared authority structure can absorb them with genuine oversight. The principle: meaningful oversight has a throughput boundary.
• Dim 11 — Formal Accountability Collapse (FAC): signals, from declared fields, that the formal attribution of responsibility appears fragmented — authority declared, but not structurally coherent at the moment of closure. FAC is not misconduct. It is the condition in which compliance remains formally visible while signals consistent with degraded oversight conditions are structurally present.

As AI agent populations grow, the question of who is responsible for what an agent decides cannot be answered by execution logs alone. The agent produces the decision. But who is accountable for it — and can that accountability be documented outside the agent's own system?

The EVIDE MCP Server (current version v1.4.0, seven tools) brings this question to machine scale. It is not a logging tool. It is an agent-to-evidentiary accountability boundary.

Many governance records capture the final output of a decision: a response, a log, a snapshot. They may not capture what happens while the decision is forming and crossing the layers of the system.

Two decisions with the same final output can have different trajectories — one stable, the other apparently stable with degraded continuity beneath the surface. A record of the final output alone may not distinguish the two.

A single closure record preserves who was declared responsible for one decision. But consequential decisions are rarely single events. They are sequences: an initial assessment, a revision after new information, an escalation, a final determination — each one closed by an authority, sometimes by different authorities, sometimes months apart.

Execution systems can link these events: a correlation ID, a trace, a parent-child relation in a log store. A linked log kept inside the system that produced it shows that records reference each other there. On its own, it does not show that each step was deposited outside that system at its own time, or that the sequence was not rewritten afterwards.

The layers above concern decisions after closure, or while they are being observed. EVIDE ANCHOR concerns a different object: the operational perimeter declared for an agent — environment, privileges, purpose, tools — together with who declared it and when EVIDE received it.

Execution systems can enforce a permission at runtime: a role, a scope, an access-control list. Some also record configurations or declarations. EVIDE ANCHOR does not enforce anything and does not validate the declarant's actual authority: it preserves explicit, attributable statements about the perimeter, held outside the operated system.

EVIDE is frequently misread as a governance dashboard, an audit log, or an AI monitoring tool. It is none of these.

EVIDE exists at the declared closure boundary. It creates evidentiary objects, held outside the originating system and verifiable by fingerprint, that record:

A further distinction is temporal: when the responsibility record comes into existence, and outside which system it is held.

This is not only a technical feature; it is an evidentiary position. What the record documents is a sequence that can be shown — declared time, intake time and the order of deposits — not a sequence that has to be assumed.

EVIDE preserves a closure state together with the authority declared in it. DAPI adds a separate element: the verified identity of the account that made the deposit. Keeping these elements apart is what lets the record say precisely what it shows.

DAPI is the identity verification layer behind every EVIDE account. In the EVIDE API intake schema (v2.1), two fields of the authority object relate to DAPI — with different meanings:

authority.dapi_number binds the deposit to the verified identity of the account that owns the API key: a mismatch is refused at intake. authority.id, authority.role and the optional authority.verification remain declarations: EVIDE records them as submitted and does not verify the declared authority's identity, role or powers.

Together, EVIDE and DAPI keep four elements distinct:

• →Verified depositing identity — DAPI identifies the account that made the deposit
• →Declared attribution — the authority and role stated in the record, preserved as declared
• →Recorded timing — the intake time, kept separate from the declared closure time
• →Separate custody — the record is held outside the originating system

Regulation (EU) 2024/1689 (the AI Act) sets obligations for AI systems according to their category and risk. The provisions discussed below concern high-risk AI systems and the parties responsible for the relevant duties — chiefly providers and, for certain duties, deployers. They cover risk management, records and human oversight:

• Article 9 — a risk management system must be established, implemented, documented and maintained in relation to high-risk AI systems, run as a continuous iterative process across the system's lifecycle.
• Article 12 — high-risk AI systems must technically allow for the automatic recording of events (logs) over the lifetime of the system, with a level of traceability appropriate to the intended purpose.
• Article 14 — high-risk AI systems must be designed and developed so that they can be effectively overseen by natural persons while in use; the people assigned to oversight must be able, among other things, to disregard, override or reverse the output and to interrupt the system.
• Article 17 — providers of high-risk AI systems must put in place a documented quality management system, which includes record-keeping and an accountability framework setting out the responsibilities of management and other staff.

EVIDE can support the preservation and later examination of evidence relevant to these duties: declared decisions, declared oversight, declared perimeters and their records. It does not by itself make a system compliant, and it does not replace any obligation that applies to providers, deployers or other parties under the Regulation.