Audit
Audit in AIEP operates at two levels. The first is the Hub’s own operational audit — the tamper-evident download log for NDA-gated materials. The second, and more significant, is the AIEP substrate’s deterministic audit architecture — the system by which every reasoning operation, evidence decision, and compliance certification is permanently, cryptographically recorded and independently verifiable.
AIEP substrate audit architecture
The AIEP audit trail is not a separate logging system appended to an AI’s outputs. It is a structural property of the constitutional stack — every operation that touches the Evidence Ledger or Reasoning Ledger produces an audit artefact as an automatic by-product.
The dual ledger
The audit infrastructure rests on two append-only ledgers:
| Ledger | What it records |
|---|---|
| Evidence Ledger | Every canonicalised artefact, identified by hash, with provenance metadata, schema version, and timestamp. Append-only. Hash-chained. |
| Reasoning Ledger | Every reasoning state entry, each referencing Evidence Ledger entries by hash. Every goal commitment, compliance certificate, suppression record, and divergence record. Append-only. Hash-chained. |
Neither ledger supports modification or deletion. A record, once appended, is permanent. The hash chain means any tampering with earlier records is detectable — the chain breaks at the point of modification.
What gets recorded
| Event | Record type | Ledger |
|---|---|---|
| Evidence artefact accepted | Canonical artefact + NormalisationManifest | Evidence Ledger |
| Evidence artefact rejected | Rejection record with violated constraint | Evidence Ledger |
| Temporal gap detected | GapArtefact with gap extent and profile version | Evidence Ledger |
| Evidence divergence detected | DivergenceRecord naming both artefacts and contradicted fields | Evidence Ledger |
| Goal committed | Goal commitment record with evidence binding | Reasoning Ledger |
| Goal re-committed | Re-commitment record with justifying evidence | Reasoning Ledger |
| Invariant check suppression | Suppression record with violated invariant | Reasoning Ledger |
| Compliance certificate generated | ComplianceCertificate with ClauseSatisfactionRecord | Reasoning Ledger |
| Compliance failure | ComplianceFailureRecord with unsatisfied clause | Reasoning Ledger |
| Dissent fork generated | Fork record with RecallScope and frontier constraint | Reasoning Ledger |
| Dissent fork closed | Termination record | Reasoning Ledger |
| Swarm consensus reached | ConsensusRecord with contributing hashes | Reasoning Ledger |
Deterministic replay
Any output produced by a GENOME-compliant substrate can be deterministically replayed from the stored ledger entries. Given the Evidence Ledger state and Reasoning Ledger entries in force at time of output production, any node can re-execute the reasoning chain and verify that the same output would result.
This is what makes the audit trail meaningful for regulators and legal proceedings — it is not a log that claims to describe what happened. It is a reproducible record from which what happened can be independently verified.
Audit without enforcement (P28)
A regulator or independent auditor may need to verify the audit trail without taking on enforcement responsibility. The deterministic audit support mechanism (P28) generates structured AuditArtefacts as a passive by-product of the admissibility determination process.
AuditArtefacts contain:
- Canonical evidence references
- Registry version identifiers in force during determination
- Deterministic admissibility outcome records
- Processing trace commitments
AuditArtefacts explicitly exclude evaluative commentary, enforcement triggers, and recommendations. They are structured factual records — suitable for submission to a regulator or independent reviewer without creating enforcement dependency.
Evidence presentation for legal proceedings (P29)
For submissions to courts, tribunals, or arbitration panels, the evidence presentation mechanism (P29) produces structured factual records from the AIEP substrate. These records present evidence without asserting a conclusion — the judgement is left to the receiving body.
This is a meaningful legal distinction. A record that says “the hash of the output matches the hash in the ComplianceCertificate generated at 14:32:07 on 14 January 2026, bound to Evidence Ledger state hash sha256:abc…” is a structured factual claim with cryptographic provenance. A record that says “the system was therefore compliant” is an interpretive assertion.
AIEP provides the former. The latter is for the tribunal.
AIEP audit vs log-based audit systems
Conventional enterprise AI audit tools — including Microsoft Purview AI Hub, which records Copilot interactions across Microsoft 365 — operate on a fundamentally different model.
Log-based audit records that an AI interaction occurred: prompt text, response text, timestamp, user identity, and policy classification. This is useful for eDiscovery, data governance, and usage monitoring.
Cryptographic commitment audit records what evidence was verified to produce the output. This is a different claim.
| Capability | Log-based (e.g. Purview) | AIEP evidence chain |
|---|---|---|
| Records that a response was generated | ✓ | ✓ |
| Records prompt and response text | ✓ | ✓ |
| Records which sources were fetched | ✗ | ✓ (artefact IDs) |
| Content hash at retrieval time | ✗ | ✓ (per-artefact) |
| Network path integrity of sources | ✗ | ✓ (P124) |
| Tamper-evident hash chain | ✗ | ✓ (P37, P80) |
| Dissent record if evidence incomplete | ✗ | ✓ (P126) |
| Independently verifiable by third party | ✗ | ✓ (chain replayable) |
| Compliance certificate auto-generated | ✗ | ✓ (ComplianceCertificate) |
A Purview log can answer “did the user receive this AI response?” AIEP’s artefact chain can answer “was this response supported by clean, unfalsified evidence from verified sources, and is that claim independently provable?”
For regulated evidence contexts — court-admissible records, FCA audit trails, FDA regulated submissions — the distinction is dispositive.
Hub operational audit log
For the Hub itself, the primary audited action is NDA-gated downloads — restricted development packs shared under a signed NDA.
Tamper-evident event chain
The Hub’s operational audit log is an append-only chain where each event links to the previous event hash. This makes later tampering detectable.
| Field | Contents |
|---|---|
timestamp | UTC |
eventType | accepted_nda / served_restricted_file / denied_request |
fileId | The specific file served or denied |
requestHash | Hashed request identifiers (privacy-first — no raw IP stored unless required) |
previousHash | Hash of the preceding record in the chain |
currentHash | Hash of this record |
VPN and proxy policy
Restricted downloads are not available when a VPN or proxy is detected. This is an evidential integrity measure — a download event whose requestor cannot be identified has reduced evidential value in a legal or regulatory context. Public downloads remain frictionless.
Infrastructure
The Hub audit log runs as a Cloudflare Worker with a Durable Object for the chain head and event storage. Full deployment plan: DEPLOYMENT_WORKER_PLAN.md.
Regulatory governance · Compliance · Security · Patents — P28, P29, P80