Verifiable Records

A verifiable record is one that any authorised party can independently confirm — without trusting the system that produced it, without re-running the inference, and without contacting the originating organisation. AIEP’s architecture makes every governed output a verifiable record by construction.

What makes a record verifiable

A record is verifiable when it satisfies three properties:

  1. Integrity — the content cannot be modified after production without detection
  2. Provenance — the evidence sources that produced it are identified and traceable
  3. Replayability — an independent party can reconstruct the reasoning path from the record alone

Conventional AI system outputs satisfy none of these. A response from a language model can be modified after the fact (no hash commitment), references no source artefacts by hash (no provenance), and cannot be replayed (no fixed reasoning state).

AIEP satisfies all three.

Integrity — hash-bound commitments

Every AIEP output carries a response_commitment: a SHA-256 hash computed over the response content, evidence artefact IDs, and timestamp at the moment of production. This commitment is written to the Evidence Ledger before the response is returned.

If the response is subsequently modified — by any party, including the operator — the commitment no longer matches. Any verifying party can detect the modification without access to the original system.

The canonical schema (aiep.canonical.schema.v3.0.0.json) defines the exact serialisation algorithm. Any two compliant implementations compute the same hash for the same inputs.

Provenance — evidence artefact chains

Every evidence artefact has:

  • A content hash (SHA-256 over the artefact content at retrieval time)
  • A source URL and retrieval timestamp
  • A chain reference linking it to the genesis record for its session

The response_commitment binds the response to its artefact list by hash. An auditor can verify that the system used exactly the sources listed — no more, no fewer.

The Evidence Rail format packages these artefacts for independent distribution. Mirrors can host AIEP evidence rails without hosting the original content.

Replayability

AIEP’s Replay Kernel allows any authorised party to reconstruct a governed session from its Evidence Ledger record. The replay produces the same evidence chain, the same artefact hashes, and the same response_commitment — confirming that the original record accurately describes the session.

Replay does not require the original AI system. It requires: the ledger record, the canonical schema version in force at the time, and the source artefacts (or their hashes if the artefacts are cached). This is what makes AIEP useful for regulatory audit — the auditor does not need to trust, or even access, the original deployment.

Negative proofs

Where evidence is absent, contradictory, or insufficient to support a conclusion, AIEP generates a Negative Proof — a signed record of the absence. The system does not produce an uncertain output and silently discard the uncertainty. The uncertainty is the record.

Negative Proofs are first-class artefacts in the Evidence Ledger. They are subject to the same hash-binding and replayability requirements as positive evidence. See Negative Proofs for the full specification.

Machine-readable verification

AIEP’s .well-known/aiep/ directory publishes machine-readable discovery endpoints. AI systems, crawlers, and verification tools can locate the current schema version, artefact hashes, and ComplianceCertificate policies without a human intermediary.

The AIEP Validator (open source) verifies any AIEP-governed record against the canonical schema. No registration, no API key.

→ Negative Proofs · Evidence Layer · How it Works · Spec · AIEP Validator