Home / Guides / Audit-Trail Crosswalk

AI decision audit trails: receipt fields to three regimes, clause by clause

Mapping current as of 2026-09-02 · clause texts retrieved 2026-09-02 (EU AI Act), 2026-09-02 (PCI DSS v4.0.1), 2026-09-02 (SOX) · field list derived from chaingraph/standard/openchain-graph-v0.4.schema.json, $defs.artifact

Compliance guidance published since 2024 converges on a short list of things an AI decision record should carry: an event timestamp, the identity and version of the model or tool, the inputs, the outputs, and some form of authorization and escalation context. Industry summaries often compress this into a "minimum field set" of about a dozen items. No single named standard enumerates that list, so this page does not treat it as authority. Instead it maps our receipt fields, one row at a time, against retrieved clause text from three actual regimes that impose audit-trail and logging duties, and states per row what the field supports, what it supports only when present, and what no field carries.

This mapping is descriptive evidence. It is not a conformity assessment. Every coverage verdict uses Supports deliberately, never "satisfies": a receipt is a record a deployer or auditor can point to; the receipt does not by itself constitute a compliance program. Regime applicability (which systems are high-risk under the EU AI Act, which components are in the cardholder data environment, which reports fall under SOX) is decided by the deployer, not by us.

The receipt fields being mapped

OpenChainGraph (OCG) v0.4 execution receipts are structured, content-hashed records of one deterministic computation. The member names below come straight from the shipped v0.4 JSON Schema ($defs.artifact). The full field-by-field predicate description lives on the OCG Execution Receipt v0.1 spec page; the EU-only reading of the same fields is on the Article 12 record-keeping mapping page.

The three regimes and their retrieved clauses

Clause texts below were retrieved from primary sources on 2026-09-02 and pinned as workspace snapshots with sha256 and source URLs. Short quotations are for identification and cross-reference.

Regime 1 of 3

EU AI Act, Article 12 record-keeping (Regulation (EU) 2024/1689)

Source: European Commission AI Act Service Desk article pages, official version of 13 June 2024 · retrieved 2026-09-02 · applicability: Art. 113(2), "It shall apply from 2 August 2026."
"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system."Article 12(1)
Logging capabilities shall enable automatic recording of events "at the time when each event occurs", addressing at least: situations which may result in the system presenting a risk (Art. 79(1)) or in a substantial modification (Art. 43(4)); post-market monitoring (Art. 72); and monitoring of operation (Art. 26(5)).Article 12(2), abridged

Article 12(3) adds a narrower floor for Annex III point 1(a) systems (remote biometric identification): start and end date-time of each use, the reference database checked, the input data that produced a match, and identification of the natural persons involved in verifying results. Article 19(1) requires providers to keep the Article 12(1) logs for at least six months. A dedicated checker for these clauses is tool 666.

Regime 2 of 3

PCI DSS v4.0.1, Requirement 10 (June 2024)

Source: PCI DSS v4.0.1 Requirements and Testing Procedures, June 2024, PCI Security Standards Council · retrieved 2026-09-02 from a publicly hosted copy of the official publication (the SSC document library is login-gated) · quotations are short excerpts
Audit logs record the following details for each auditable event: user identification; type of event; date and time; success and failure indication; origination of event; identity or name of affected data, system component, resource, or service.Requirement 10.2.2, abridged
Audit log files are protected to prevent modifications by individuals (10.3.2) and are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify (10.3.3). File integrity monitoring or change-detection mechanisms ensure existing log data cannot be changed without generating alerts (10.3.4).Requirements 10.3.2 through 10.3.4, abridged

Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis (10.5.1). System clocks and time are synchronized using time-synchronization technology (10.6.1). Failures of critical security control systems, including audit logging mechanisms, are detected, alerted, and addressed promptly (10.7.2).

Regime 3 of 3

Sarbanes-Oxley Act of 2002 (Pub. L. 107-204)

Source: U.S. Government Publishing Office, govinfo permanent collection, official text · retrieved 2026-09-02 · U.S. federal statute, public domain
Each annual report ... to contain an internal control report, which shall state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and contain an assessment ... of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.Sec. 404(a), abridged
Whoever knowingly alters, destroys, mutilates, conceals, covers up, falsifies, or makes a false entry in any record, document, or tangible object with the intent to impede, obstruct, or influence the investigation or proper administration of any matter ... shall be fined under this title, imprisoned not more than 20 years, or both.Sec. 802(a), adding 18 U.S.C. 1519

SOX names no log fields. Its audit-trail relevance is control assessment and attestation (Sec. 302(a)(4)(C)-(D), 404(a)-(b)), criminal exposure for record falsification (18 U.S.C. 1519), and statutory retention floors such as the five-year audit-workpaper rule (18 U.S.C. 1520(a)(1)). Rows against SOX are therefore evidentiary by nature.

The crosswalk

Filter by regime, or read the whole table. Each row names the receipt member, the clause it is read against, and a coverage verdict with the reasoning. Rows that name no member are regime requirements no receipt field addresses; they are stated rather than omitted.

Supports carried by default Supports when present optional member Not carried stated gap Out of scope deployer or pipeline duty
Receipt memberRequirement and clauseCoverage
generated_at, execution_hash Automatic recording of events "at the time when each event occurs" §12(2) Supports Each execution emits one timestamped, content-hashed record with no operator action, which is the minimum unit of an automatic log entry.
chain.parent_hashes, chain.parent_tool_ids, chain.chain_depth Logging "over the lifetime of the system" §12(1) Supports Hash-linked lineage turns isolated entries into an accumulated, verifiable chain across the system lifetime.
tool_id, tool_version, chaingraph_version, supersedes (opt.) Identifying "situations which may result in ... a substantial modification" (Art. 43(4)) §12(2)(a) Supports A version change between receipts for one tool_id is observable in the log series; supersedes records the correction explicitly where used.
audit_signature.deterministic_run, zero_pii_verified, client_side_executed Identifying "situations which may result in the AI system presenting a risk" (Art. 79(1)) §12(2)(a) Supports Per-run posture booleans; a false value is precisely the kind of event a risk-monitoring log needs to surface.
policy_parameters, output_payload "Facilitation of post-market monitoring" (Art. 72) and monitoring of operation (Art. 26(5)) §12(2)(b)-(c) Supports The verbatim hashed inputs and outputs are the concrete record an operator or auditor inspects to see what the system did.
anchor_bindings (opt.) Post-market monitoring evidence §12(2)(b) Supports when present An RFC 3161 timestamp or transparency-log binding evidences existence-at-a-time independently of the operator.
(no member) "Recording of the start and end date and time of each use of the system" §12(3)(a) Not carried Applies only to Annex III point 1(a) systems. A receipt records one event time, not a session start/end pair.
(no member) "Recording of the reference database against which input data has been checked" §12(3)(b) Not carried No reference-database pointer field exists; the obligation is confined to Annex III point 1(a) systems.
policy_parameters "Recording of the input data for which the search has led to a match" §12(3)(c) Supports when present Inputs are carried verbatim in the hash preimage, so matched inputs are recorded where the workflow runs a matching step.
(no member, deliberate) "Recording of the identification of the natural persons involved in the verification of the results" §12(3)(d) Not carried Receipts carry no human-identity field. See the gaps section: actor identity attaches only through opt-in signing, and then only as a key identity rather than a natural person.
retention_class (opt.) Providers keep Art. 12(1) logs "for a period appropriate to the intended purpose ... and of at least six months" §19(1) Out of scope retention_class is prune-eligibility metadata; it commits no one to any retention period. The keeping duty sits with the provider or deployer.
generated_at "Date and time" recorded for each auditable event §10.2.2 Supports One timestamped event record per execution.
execution_hash over policy_parameters + output_payload Logs "protected to prevent modifications by individuals" §10.3.2; change-detection so "existing log data cannot be changed without generating alerts" §10.3.4 Supports The record is content-addressed: any post-hoc edit of inputs or outputs breaks the hash, a per-record change-detection property anyone can verify offline.
anchor_bindings (opt.) Logs "promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify" §10.3.3 Supports when present External anchoring is point-in-time evidence of retention outside the operator's own storage. The backup pipeline itself remains a deployer control.
audit_signature.signatures, audit_signature.proof (opt.) "User identification" per auditable event §10.2.2 Not carried by default; Supports when present Opt-in signing attaches a did:key signer identity to the envelope. An unsigned receipt names no user, by design (see gaps).
tool_id, tool_version "Identity or name of affected data, system component, resource, or service" §10.2.2 Supports The computing component is named and versioned on every record.
output_payload, compliance_flags, mandate_type "Success and failure indication" and "Type of event" per auditable event §10.2.2 Supports when present Outcome and classification live in the payload and optional tagging members; a receipt whose payload omits an outcome indicator supports these details only to that extent.
generated_at + anchor_bindings.gen_time (opt.) "System clocks and time are synchronized using time-synchronization technology" §10.6.1 Not carried as a control; Supports when present as evidence: generated_at is the issuer clock, and an RFC 3161 anchor corroborates it against an independent TSA clock where attached.
(no member) Event-class coverage: individual user access to cardholder data, administrative actions, access to audit logs, invalid logical access attempts, credential changes, log initialization or pausing, system-object creation and deletion §10.2.1.1 through §10.2.1.7 Out of scope These are infrastructure audit-log duties across the cardholder data environment rather than fields of a per-decision receipt. A receipt never carries authentication events.
(no member) Daily log review (10.4.1), read-access restriction to those with a job-related need (10.3.1), and prompt detection and alerting of critical control failures including audit logging mechanisms (10.7.2) Out of scope Review, access control, and alerting are operating controls of a logging pipeline. Receipts are records; review and alerting live in the pipeline around them.
retention_class (opt.) "Retain audit log history for at least 12 months, with at least the most recent three months immediately available" §10.5.1 Out of scope The member classifies pruning eligibility; it makes no storage-duration commitment. Retention is the deployer's control to design and evidence.
(all members, as evidence) Management's assessment of "the effectiveness of the internal control structure and procedures ... for financial reporting" §404(a)(2); officer evaluation and conclusions §302(a)(4)(C)-(D) Supports Receipts are control-operating evidence an issuer can cite in an internal-control assessment: deterministic processing, verifiable inputs and outputs, and tamper-evident records are the substance information-processing controls are assessed for. SOX names no log fields, so no row can satisfy it directly.
audit_signature.signatures, anchor_bindings (opt.) Auditor attestation on management's assessment §404(b) Supports when present Independently verifiable evidence (signatures, external anchors) is the kind a registered public accounting firm can test without relying on management's own records.
execution_hash Penalties for knowingly falsifying records §802(a), adding 18 U.S.C. 1519; five-year audit-workpaper retention §18 U.S.C. 1520(a)(1) Supports Tamper-evident records make silent falsification detectable and keep retained evidence testable. The statute binds conduct and retention periods, not record formats, so the receipt's role is evidentiary.
(no member) Any SOX clause prescribing log field content Out of scope No such clause exists in the statute. Stated as a regime fact rather than a gap in the receipt.

Honest gaps, and why several are deliberate

No actor identity by default. The convergence summaries list actor or agent identity, and PCI DSS 10.2.2 names "user identification". Our receipts deliberately carry no actor field: identity attaches only when the emitting party opts into signing (audit_signature.signatures or proof), and a did:key proves control of a key rather than a legal identity. Signing is also de-anonymizing, which is exactly why it is opt-in. A deployment whose regime requires per-event user identification must enable signing or pair receipts with its own identity layer.
Retention is not carried. EU AI Act Article 19(1) floors log-keeping at six months; PCI DSS 10.5.1 requires twelve months with three immediately available. The receipt records what happened; it does not commit anyone to keeping it. retention_class (optional, v0.8.18) classifies prune eligibility and is excluded from the hash preimage. Keeping the logs is the deployer's control, and anchoring a receipt externally is the strongest in-artifact evidence that it existed at a point in time.
Review, alerting, and clock discipline are pipeline duties. PCI DSS 10.4.1 (daily review), 10.7.2 (failure alerting, including of audit logging mechanisms), 10.3.1 (read-access restriction), and 10.6.1 (time synchronization) are controls over a logging operation. A receipt is a record; these are controls over the operation that produces and handles records, so no row maps them to a field. anchor_bindings is the one in-artifact corroboration: an RFC 3161 timestamp checks generated_at against an independent clock.
Event-class coverage in PCI DSS 10.2.1.1 through 10.2.1.7 (credential changes, invalid access attempts, log pausing, object deletion, and similar) describes what a cardholder-data-environment audit log must capture across the whole estate. None of it is a per-decision field, so receipts neither carry nor claim it.
EU AI Act Article 12(3) applies only to Annex III point 1(a) remote biometric identification systems, and three of its four required elements (session start/end, reference database, human-verifier identity) have no receipt member. This matches the stated gap on the EU-only mapping page, and tool 666 treats the 12(3) floor as a separate gate condition for the same reason.

Verify, do not take our word

The claims above degrade gracefully by construction, and every one of them is checkable without trusting us:

What this page is

A descriptive crosswalk against quoted clause text, current as of the retrieval dates above: standards move (PCI DSS refreshes on a multi-year cycle, EU AI Act amendments are pending, PCAOB continues to issue SOX attestation standards), and this page promises no updates. Nothing here is legal advice or a conformity assessment, and it makes no claim that any deployment satisfies any regime. Verdicts describe what a field carries, and the deployer decides what their regime requires of them.