Every OpenChainGraph (OCG) v0.4 execution receipt is a structured, content-hashed record of one computation. This page maps the receipt's own members to the specific automatic-logging obligations set out in Article 12 of the EU AI Act (Regulation (EU) 2024/1689), and states plainly where the receipt does not cover a requirement rather than stretching the claim.
Quoted directly from the Regulation, not a summary:
"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 12(1)
"In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk … or in a substantial modification; (b) facilitating the post-market monitoring …; and (c) monitoring the operation of high-risk AI systems …" Article 12(2)(a)–(c)
Article 12(3) adds a further, narrower logging floor that applies only to the Annex III point 1(a) systems (remote biometric identification): recording the period of each use, the reference database checked, the input data that produced a match, and the identity of the natural person who verified the result (per Article 14(5)). OCG receipts are general-purpose and do not carry a reference-database field or a human-verifier identity field, so Article 12(3) is a stated gap below, not mapped.
Left column: the shipped v0.4 artifact members, re-derived directly from chaingraph/standard/openchain-graph-v0.4.schema.json $defs.artifact (not from memory). Right column: the specific Article 12 requirement each member evidences. Every row uses Supports deliberately, never "satisfies": a receipt is evidence a deployer or auditor can point to, not itself a compliance program. Article 12 obliges the AI system to allow logging, and these members are the concrete artifact of that logging.
| Receipt member | Article 12 ref | How it evidences the requirement |
|---|---|---|
generated_at + execution_hash |
Art. 12(1) | Supports "automatic recording of events (logs)." Every tool execution that emits a receipt produces, without operator action, a timestamped (generated_at) content-hash (execution_hash) of that specific event: the minimum unit of an automatic log entry. |
chain.parent_hashes, chain.parent_tool_ids, chain.chain_depth |
Art. 12(1) | Supports "over the lifetime of the system." A receipt's chain object links it to the prior receipts it descends from, so a single artifact carries its own lineage: logs accumulate as a verifiable chain rather than isolated, unlinked entries. |
tool_version, chaingraph_version, supersedes |
Art. 12(2)(a) | Supports "identifying … a substantial modification." A version change between two receipts for the same tool_id is directly observable in the log, and supersedes (when present) explicitly records that one artifact corrects or replaces an earlier one: a modification event captured in the receipt itself. |
audit_signature.deterministic_run, audit_signature.zero_pii_verified, audit_signature.client_side_executed |
Art. 12(2)(a) | Supports "identifying situations that may result in … presenting a risk." These booleans flag, per execution, whether the run's determinism and privacy posture held; a false value on any of them is exactly the kind of event a risk-monitoring log needs to surface. |
tool_id, chain.parent_hashes, chain.chain_depth (across the receipt series for one tool) |
Art. 12(2)(b) | Supports "facilitating post-market monitoring." Because every receipt for a given tool_id chains to its predecessor, the receipt series is a longitudinal, tamper-evident record a deployer can review after deployment: the structural basis post-market monitoring needs. |
anchor_bindings (optional, §20) |
Art. 12(2)(b) | Supports post-market monitoring's evidentiary strength when present: binding a receipt's hash to an independent external timestamp anchor means the monitoring record's existence-at-a-point-in-time does not rely solely on the operator's own say-so. Optional, and its absence does not break the mapping above. |
policy_parameters, output_payload |
Art. 12(2)(c) | Supports "monitoring the operation" of the system. These two members are the actual hashed inputs and outputs of the run: the concrete decision record an operator or auditor inspects to see what the system actually did on a given execution. |
audit_signature.signatures, audit_signature.proof, audit_signature.compute_proof, audit_signature.build_identity (all optional) |
Art. 12(2)(c) | Supports operation-monitoring where present: a cryptographic signature, a zero-knowledge proof, or a pinned build identity lets a party monitoring operation verify the run happened as recorded, without trusting the receipt's producer. Optional fields: absence is conformant and simply means this stronger evidentiary tier was not attached to that run. |
mandate_type, semantic_profile, dct:conformsTo, compliance_flags, private_inputs, input_attestations, policy_parameters_hash: not mapped. These members are real and shipped, but each serves a different purpose (taxonomy classification, ISO 20022 alignment, licensing/conformance metadata, generic compliance tagging, privacy commitments, input attestations, and an optional standalone hash of policy_parameters). None of them, on inspection, specifically evidences an Article 12 automatic-logging requirement, and including them would be exactly the kind of overclaim this mapping is built to avoid.
This mapping is descriptive, not a conformity assessment. It shows that the fields OCG receipts already ship line up with what Article 12 asks a high-risk AI system's logging to capture, but it does not itself determine whether any particular deployment is a "high-risk AI system" under the Regulation, and it is not legal advice. A deployer relying on OCG receipts as Article 12 evidence should independently confirm applicability and completeness against their own risk classification.