Watch the gate. Make its case.

This AI audit trail example follows a synthetic vendor-risk review: a request arrives, a model output is recorded, controls report a result, and the evidence bundle is sealed. The event log describes the sequence. The attestation index ties nine evidence files to their hashes and a signed root.

Every record below is a public synthetic fixture, dated June 12, 2026. It illustrates the evidence format; it is not a customer review or a finding that a vendor meets a regulation.

01 · Which action?

Event log: event_id is wf-2026-06-12-001; workflow is vendor-risk-review.

The ID connects the described steps. An ID alone does not establish who performed them or prove the events occurred.

02 · What was the result?

Control report: verdict is all_required_controls_passed, with three named controls marked pass.

This is the fixture's recorded control result. It does not establish that the controls were sufficient or that a real workflow is compliant.

03 · When was it recorded?

The index declares issued_at: 2026-06-12T12:00:00.000Z. The event log separately records four times, from 09:00:04Z to 09:05:09Z.

These are declared timestamps. The example contains no independent timestamp-authority proof.

04 · Which policy version?

Policy map names policies and their gates, but contains no policy-version field. The index's service_version: 0.4.0 identifies the producer version.

The producer version is not a policy or model version. This example cannot establish which revision of a policy was applied.

05 · Do the file bytes match?

The index's artifacts[].sha256 records the hash of each evidence file. For control_gate_report.json, it is 34c75e1c1f29cb00157347d77e80b7c3c5fa9d954ed5ab8cd98fa37536607248.

Recompute SHA-256 over the downloaded bytes, without reformatting the JSON. A match checks those bytes against the index; it does not verify the truth of the report.

06 · How are the files tied together?

The index declares root_scheme: merkle-rfc6962-sha256 and attestation_root: 0ae6c016b88c4dc0b398e4ee06b300f00e97b457e5844f90e09945ff555dde81.

Recompute using the declared ordering and legacy duplicate-last rule in root_construction. A matching root does not show that every relevant real-world event was included.

07 · Who signed?

Signature record: algorithm is ed25519; key_origin is synthetic-demo. The signature and public key are included.

The signature checks the root against that supplied key. This demo key does not establish a trusted production signer or a customer's identity.

08 · What about the source payload?

Provenance chain uses illustrative labels such as synthetic-input-packet-sha. Control references such as ctrl-source-001 are also placeholders.

Those labels are not verifiable payload hashes. The real file hashes in the attestation index verify the fixture files, not an underlying customer input or model output.

Repeat the check.

1. Select Workflow in the demo above and run the intact record. The browser checks the evidence files against the index and recomputes the declared root.
2. Inspect the signature result separately. A browser that cannot verify Ed25519 reports that limitation; a matching root alone is not a verified signature.
3. Run the tampered record to see a changed file fail its check. Download the archive to inspect the same eleven JSON files: nine artifacts, the index, and the signature record.

For a live workflow, review the missing context too: source identity, policy and model revisions, completeness, and who trusts the signing key. A reproducible evidence check supports that review; it cannot make those decisions for you.