Decision-Receipt Crosswalk · OpenChainGraph v0.4
OCG Artifact as Decision Receipt: Alignment with Art 12, Reg B, ASC 815, and AAT
For compliance officers, auditors, and engineers evaluating verifiable decision records. An OpenChainGraph artifact is a self-verifying decision receipt: its field set maps directly onto what four distinct decision-record regimes require. This page shows that alignment field by field, using the exact section names from the OCG specification. No custom receipt format is needed; the shipped artifact is already the record.
EU AI Act Art 12(2) · Aug 2026 enforcement
ECOA Reg B §1002.12 · 25-month retention
ASC 815 · Hedge contemporaneous documentation
IETF draft-sharif AAT · alignment target
Alignment map · not a conformance claim
DEADLINE: EU AI Act Annex III 5(b) (creditworthiness) and 5(c) (life/health insurance pricing) are high-risk. Art 12 logging obligations enforce August 2026 (verify formal-adoption status of the Digital Omnibus, which defers some provisions to December 2027, but Art 12 logging is NOT deferred). Deployer Art 26 duties require maintaining these logs. Action is required now for systems in these categories.
ALIGNMENT, NOT CERTIFICATION: No harmonised Art 12 technical standard exists (ISO/IEC DIS 24970 is incomplete; JTC 21 work ongoing). IETF draft-sharif-agent-audit-trail-00 expires September 2026. This is an alignment map, not a conformance claim. OCG anchoring is above current market practice. NOT LEGAL ADVICE: citations are reference pointers; verify with qualified counsel before relying on them.
The thesis (from STP research §11): OCG §12 policy_parameters + §17 audit_signature.build_identity + §4 execution_hash + §20 anchor_bindings + §13.11/§13.12 exports already equal the field sets of these four regimes 1:1. Where a gap exists, this page says so honestly rather than forcing a fit.
The OCG artifact field inventory
Every field referenced in the crosswalk tables below, with its SPEC.md section. These are the real field names from the specification, not paraphrases.
§1 Artifact envelope tool_id · mandate_type · policy_parameters · output_payload · execution_hash · parent_hashes · chain_depth
§4 Execution hash SHA-256 over RFC 8785/JCS-canonical {policy_parameters, output_payload} via kernels/_hash.mjs
§5 mandate_type taxonomy agent_guardrail_mandate · compliance_mandate · model_governance · risk_assessment · …
§9 Party identity (did:key) audit_signature.signatures[].keyid (did:key · multicodec Ed25519 · z6Mk… form)
§12 Compute Binding policy_parameters fold-in; kernel at kernels/<tool_id>.kernel.mjs
§13.11 VC export chaingraph_export:vc · W3C VC 2.0 · ocg:hashAnchor re-states execution_hash
§13.12 SD-JWT export selective-disclosure · execution_hash always-disclosed
§16 Proof Binding audit_signature.proof · type:"DataIntegrityProof" · cryptosuite:"eddsa-jcs-2022"
§17 Kernel Identity Binding audit_signature.build_identity.kernel_digest · .buildType · .source_ref
§18 Compute-Integrity Proof audit_signature.compute_proof · type:"ZkVmReceipt" · imageId · journal · seal
§20 Anchor Binding anchor_bindings[] · type:"rfc3161-tst" · anchored_hash · gen_time · proof (DER) · signer_cert_chain_b64
Table 1: EU AI Act Art 12(2) high-risk AI logging
Reg. 2024/1689 Art 12(1)-(2) · Annex III 5(b) creditworthiness, 5(c) life/health insurance pricing · Art 26 deployer duties · Enforcement: August 2026 (verify Digital Omnibus status for Annex III high-risk obligations)
Art 12(1) requires high-risk AI systems to automatically record events relevant to the system's purpose throughout its lifetime. Art 12(2) specifies at minimum: input data, output, period of use, model/version identity, reference context for verification, and identification relevant to the decision. Art 26 places retention duties on deployers.
| Art 12 requirement |
OCG artifact field |
How the field satisfies the requirement |
§Ref |
| Input data (inputs to each individual decision) |
policy_parameters |
Folded into the execution_hash preimage (RFC 8785/JCS canonical); any change to inputs produces a different hash, providing tamper-evident input logging. |
§4, §12 |
| Output / decision result |
output_payload |
The decision output (score, classification, recommendation) is recorded in the artifact envelope and co-hashed with policy_parameters into execution_hash. |
§1, §4 |
| Timestamp / period of use |
anchor_bindings[].gen_time (rfc3161-tst) |
RFC 3161 genTime from an independent TSA provides a tamper-evident, third-party-verified timestamp proving when the execution_hash existed. Verbatim DER storage means openssl ts -verify remains possible independently, decades later. |
§20 |
| Model / algorithm version (the exact logic that ran) |
audit_signature.build_identity.kernel_digest & .source_ref |
kernel_digest is a sha256:-prefixed digest of the deployed kernel source bytes. source_ref is a dereferenceable commit URL. Together they pin the exact logic version to a published, verifiable source. |
§17 |
| Reference context / verification path |
execution_hash + policy_parameters |
§4 deterministic re-execution: a supervisor with the same inputs and the same kernel can recompute the identical execution_hash, providing a verification path without additional infrastructure. |
§4 |
| Lifetime retention (supervisor-verifiable records) |
anchor_bindings[].proof (verbatim DER) + anchor_bindings[].signer_cert_chain_b64 |
The verbatim DER and signer certificate chain are stored in the artifact so offline verification remains possible after the TSA's own systems are decommissioned. Recommended multi-TSA redundancy (§20) strengthens retention. |
§20 |
| Compute-integrity proof (optional, exceeds Art 12) |
audit_signature.compute_proof (ZkVmReceipt) |
A zkVM receipt cryptographically proves the named kernel produced the recorded output from the recorded inputs, enabling verification without re-execution. Art 12 does not require this; it is above the bar. |
§18 |
| Annex IV technical documentation tie (provider duty) |
audit_signature.build_identity.kernel_digest + .source_ref + §13.11 vc export |
Annex IV requires providers to document the training/development methodology and the logic. The §17 binding ties each decision record back to a versioned source reference. The §13.11 VC export embeds execution_hash via ocg:hashAnchor, enabling a notified body to link a run log to an Annex IV documentation package. |
§13.11, §17 |
| Confidence / override flag |
(output_payload, user-authored) |
Art 12 may require confidence scores and override flags. These are not OCG-native fields; they must be included as named keys inside output_payload by the implementing tool. OCG does not define their schema. |
§1 |
| Natural-person identification field (Annex III 1(a) biometric scope) |
(policy_parameters, user-authored) |
For biometric-identification high-risk systems (Annex III 1(a)), Art 12(2) requires recording the identification of natural persons involved. OCG is zero-PII by design; this field would need to be a pseudonymised or hashed reference authored into policy_parameters by the deployer. Not an OCG-native field. |
§12 |
Table 2: ECOA Reg B §1002.12 record retention
12 CFR §1002.12 · Equal Credit Opportunity Act · 25-month retention from adverse action / notification · §1002.12(b)(3) computerized/regenerable records accepted
Reg B §1002.12 requires creditors to retain credit applications, adverse action notices, and related material for 25 months (consumer credit). Section §1002.12(b)(3) explicitly blesses computerized records maintained in a format that can be regenerated in a readable form within a reasonable time. The OCG artifact is the regenerable computerized record; RFC 3161 anchoring exceeds the bar by adding independent third-party proof of when the record existed.
| Reg B §1002.12 requirement |
OCG artifact field |
How the field satisfies the requirement |
§Ref |
| 25-month retention of the credit decision record |
anchor_bindings[].proof (verbatim DER) + signer_cert_chain_b64 + gen_time |
The RFC 3161 TST embedded verbatim in the artifact is verifiable decades after the TSA issues it (verbatim DER, pinned signer chain). No external TSA infrastructure is required to verify retention; the DER and chain are self-contained in the artifact. |
§20 |
| Computerized / regenerable record (§1002.12(b)(3)) |
execution_hash + policy_parameters |
§4 deterministic re-execution: the same inputs + the same pinned kernel yield the identical execution_hash. Any party with the artifact can regenerate the readable output, satisfying the regenerability standard explicitly endorsed by §1002.12(b)(3). |
§4, §12 |
| Application inputs (the credit application itself) |
policy_parameters |
Structural/synthetic credit inputs are folded into the execution_hash preimage. Any modification is detectable; the record of what was submitted is cryptographically bound to the decision output. |
§12 |
| Decision output (approval, denial, counterproposal) |
output_payload |
Recorded in the artifact envelope and co-hashed. The output is inseparable from the input record without invalidating the execution_hash. |
§1, §4 |
| Adverse action notice linkage (FCRA §615(a) cross-reference) |
§13.11 vc export (ocg:hashAnchor) or §13.12 SD-JWT export (execution_hash always-disclosed) |
An adverse action notice that references the execution_hash ties the notice to the retained record. The VC export's ocg:hashAnchor and the SD-JWT's always-disclosed execution_hash both provide a verifier-resolvable link back to the canonical artifact. |
§13.11, §13.12 |
| Record integrity / tamper-evidence |
execution_hash |
SHA-256 over RFC 8785/JCS-canonical inputs and output. Any field alteration, including whitespace changes, produces a different hash, detectable by any party who recomputes. |
§4 |
| Supervisor / examiner access path |
execution_hash + anchor_bindings |
A regulator with the artifact can recompute the execution_hash against policy_parameters and output_payload offline, then verify the RFC 3161 TST binding to confirm the record's existence at a point in time. No proprietary toolchain required. |
§4, §20 |
Table 3: ASC 815 hedge contemporaneous documentation
FASB ASC 815-20-55 · Designation-date documentation requirement · Anti-backdating · Hedge effectiveness assessment method
ASC 815 requires formal documentation of a hedging relationship to exist at or before the date the entity first applies hedge accounting (at designation). This documentation must identify the hedging instrument, the hedged item, the nature of the risk being hedged, and how effectiveness will be assessed. The anti-backdating requirement is the critical control: the documentation must provably exist at designation. RFC 3161 anchoring is the strongest available fit: an independent TSA clock proving the artifact existed at a specific time is the precise answer to the anti-backdating requirement. This is noted in FASB's own rationale for the contemporaneous requirement.
| ASC 815 requirement |
OCG artifact field |
How the field satisfies the requirement |
§Ref |
| Designation-date documentation (must exist at inception; anti-backdating) |
anchor_bindings[].gen_time + anchor_bindings[].proof (rfc3161-tst) |
The RFC 3161 TST, issued by an independent TSA, proves the execution_hash existed no later than gen_time. This is the exact evidence pattern the anti-backdating requirement demands: a timestamp from a clock the documenting party does not control. |
§20 |
| Effectiveness assessment method (how effectiveness will be assessed) |
audit_signature.build_identity.kernel_digest + .buildType + .source_ref |
§17 identifies the exact kernel version used to compute effectiveness. The kernel_digest is a sha256:-prefixed digest of the source; source_ref is a dereferenceable commit pointer. Together they pin the methodology to a verifiable artifact, not a prose description. |
§17 |
| Hedging relationship description (hedged item, hedging instrument) |
policy_parameters |
Structural inputs describing the hedged item and instrument (notional, tenor, rate reference, etc.) are folded into the execution_hash preimage. They are co-hashed with the output and cannot be altered after anchoring without invalidating the TST binding. |
§12 |
| Effectiveness test outcome / result |
output_payload |
The result of the effectiveness assessment (e.g., dollar-offset ratio, regression result) is recorded in output_payload and co-hashed into execution_hash. The output cannot be separated from the methodology identity or the timestamp without breaking the chain. |
§1, §4 |
| Cryptographic proof that the documented method ran (optional, exceeds ASC 815) |
audit_signature.compute_proof (ZkVmReceipt) |
A §18 receipt proves the named kernel (identified in §17) actually produced the recorded output from the recorded inputs. ASC 815 does not require this; it is above the contemporaneous-documentation bar. |
§18 |
| Narrative description of risk management objective and strategy |
(not an OCG field) |
ASC 815 requires a prose description of the entity's risk management objective and strategy. This is a free-text obligation; OCG does not define a narrative field. The artifact anchors WHEN the kernel-based effectiveness test was set up, but the strategy narrative remains a separate document. Implementations should reference the execution_hash from that document to tie them together. |
— |
Table 4: IETF draft-sharif-agent-audit-trail (AAT)
draft-sharif-agent-audit-trail-00 · Expires September 2026 · SHA-256 chaining per RFC 8785 JCS · Agent identity · Action class · Outcome · Trust level · Optional ECDSA
The AAT draft defines a JSON record structure for agentic AI audit trails: agent identity, action class, outcome, trust level, SHA-256 chaining using RFC 8785 JCS canonicalization, and an optional ECDSA signature. OCG was independently designed around the same standards (RFC 8785/JCS, SHA-256, Ed25519) and its field set maps directly onto AAT's schema. Note: AAT specifies optional ECDSA; OCG §16 uses Ed25519 via eddsa-jcs-2022. Both are asymmetric signature schemes providing equivalent security properties; Ed25519 is the W3C Data Integrity recommended curve.
| AAT field |
OCG artifact field |
How the field satisfies the requirement |
§Ref |
| Agent identity (agentId) |
audit_signature.signatures[].keyid |
A did:key identifier (multicodec Ed25519, z6Mk... form) published in the in-toto/DSSE signatures array. Self-describing and resolvable without a key registry per §9 party-identity spec. |
§9 |
| Action class / task type |
mandate_type |
The §5 mandate_type taxonomy (agent_guardrail_mandate, compliance_mandate, model_governance, risk_assessment, etc.) maps directly to AAT's action_class categorization of what the agent did. |
§5 |
| Outcome |
output_payload |
The decision output of the agent action, co-hashed with inputs in execution_hash. The outcome is immutable once anchored. |
§1, §4 |
| Trust level / assurance grade |
audit_signature.proof (DataIntegrityProof) + audit_signature.compute_proof (ZkVmReceipt) |
§16 DataIntegrityProof signals authenticated attestation (a named key vouches). §18 ZkVmReceipt signals compute-integrity (the exact kernel provably ran). Together they constitute a graded trust signal matching AAT's trust_level concept: L1 (hash only) < L2 (signed) < L3 (zkVM proved). |
§16, §18 |
| SHA-256 chaining per RFC 8785 JCS |
execution_hash (via kernels/_hash.mjs) |
OCG §4 specifies exactly this: WebCrypto SHA-256 over the RFC 8785/JCS-canonical JSON of {policy_parameters, output_payload}, computed by the shared kernels/_hash.mjs canonicalizer used identically in the browser tool, the MCP Worker, and CI. The chaining mechanism is byte-identical to AAT's requirement. |
§4 |
| Chain links (prior record reference) |
parent_hashes[] |
The §1 artifact envelope supports parent_hashes[] carrying execution_hashes of prior artifacts in the chain, and chain_depth tracking depth. This maps directly to AAT's record-chaining requirement. |
§1 |
| Optional signing (ECDSA) |
audit_signature.proof (eddsa-jcs-2022) |
§16 DataIntegrityProof uses Ed25519 via the W3C eddsa-jcs-2022 cryptosuite over the RFC 8785/JCS-canonical artifact. Ed25519 and ECDSA-P256 are equivalent security-level asymmetric signature schemes; AAT's requirement is "optional signing," which §16 satisfies. |
§16 |
| Record timestamp |
anchor_bindings[].gen_time (rfc3161-tst) |
Optional in AAT; the §20 RFC 3161 binding exceeds the AAT timestamp requirement by providing a third-party-independent timestamp rather than a local clock. This is ABOVE what AAT requires, not a gap. |
§20 |
Caveats and limitations
Alignment, not certification
No harmonised technical standard exists for EU AI Act Art 12 logging at the time of this writing (ISO/IEC DIS 24970 is an incomplete draft; JTC 21 work is ongoing). IETF draft-sharif-agent-audit-trail-00 is an individual submission expiring September 2026. ECOA Reg B §1002.12 and ASC 815 each have their own interpretive history. This page is an alignment map, not a conformance certificate or legal opinion. Do not represent an OCG artifact as "certified," "compliant with," or "conformant with" any of these regimes based on this mapping alone. Regulatory and audit acceptance depends on the specific deployment, the jurisdiction, and the evolving interpretive guidance of each regime.
OCG anchoring is above current market practice for decision logging. The market has not yet converged on a standard for cryptographic decision-receipt formats in any of the four regimes above. This mapping shows that the OCG artifact field set satisfies the substantive requirements, not that any regulator has formally blessed the format.
Not legal advice
Regulatory citations on this page are reference pointers to the relevant legal instruments. They are not legal advice. Verify all Article, Section, and Annex references against the consolidated legal texts and current interpretive guidance before relying on them for compliance decisions. Engage qualified legal counsel for your specific situation.
Related tools and MCP nodes
These tools implement the decision-log and audit-trail constructs that produce OCG artifacts aligned with the crosswalk above. AI governance conformity chains are in the AI Governance hub.
AI Decision Logs · forthcoming on main
AI Decision Log Record Builder
Art 12-aligned record builder: input digests, output, timestamp, model version, confidence, override flag, and retention metadata. Produces a hash-chained artifact with optional RFC 3161 anchor. Implements the Art 12(2) crosswalk (Table 1) end to end.
build_ai_decision_log_record
AI Decision Logs · forthcoming on main
Agent Audit Trail Validator
Conformance validator for IETF draft-sharif-agent-audit-trail: JSON records, agent identity, action class, outcome, trust level, RFC 8785 JCS SHA-256 chaining. Implements the AAT crosswalk (Table 4). Zero existing conformance tools in this space.
validate_agent_audit_trail
AI Decision Logs · forthcoming on main
Annex III Decisioning Obligations Classifier
Extends the AI Act high-risk fit tool with financial-services payload: Annex III 5(b)/(5(c) classification, Art 12 + Art 26 deployer duties, FRIA, EU database registration, and enforcement dates.
classify_annex3_decisioning_obligations
AI Decision Logs · forthcoming on main
BIFSG Bias Threshold Tester
Colorado Reg 10-1-1 / SB 21-169 quantitative test: p<0.05 AND 5pp approval-rate marginal effect; premium/$1,000 face 5% above average. Inputs are aggregate regression outputs only; execution-hashed test run IS attestation evidence for Dec-1 annual attestation.
test_bifsg_bias_thresholds
AI Governance hub · cluster 13
AI Governance & Conformity Guide Hub
Guide hub for AI governance: EU AI Act classification, FRIA, post-market monitoring, GPAI, agentic risk, fairness, and audit-pack chains. Entry point for the full AI governance conformity lifecycle.
Guide hub
Anchorproof · anchor.ainumbers.co/mcp
Anchor Hash + Anchor Batch (live at anchor.ainumbers.co/mcp)
anchor_hash: single execution_hash + RFC 3161 TST (Sigstore, DigiCert, Sectigo, FreeTSA). anchor_batch: N leaf hashes to RFC 6962 Merkle root, one TST, per-leaf inclusion proofs. These are the §20 anchor_bindings tools in production. For high-volume decision logging (Art 12, Reg B), anchor_batch is the only viable architecture at scale.
anchor_hash · anchor_batch
OCG verifiable-evidence ladder
These four regimes require different evidence strengths. The OCG artifact supports a composable ladder; implement the level that matches your obligation.
L1 · §4 execution_hash Tamper-evidence. Any change to inputs or output is detectable. Sufficient for regenerable-record standards (Reg B §1002.12(b)(3)).
L2 · §16 audit_signature.proof Authenticated attestation. A named key vouches for the artifact (eddsa-jcs-2022, Ed25519). Satisfies AAT optional-signing + IETF agent-identity fields.
L3 · §20 anchor_bindings Third-party timestamp. Independent TSA proves existence by a point in time. Required for: ASC 815 anti-backdating, Reg B 25-month retention, Art 12 timestamp obligation.
L4 · §18 compute_proof Compute-integrity proof. zkVM receipt proves the named kernel produced this output from these inputs. Above all four regimes; eliminates re-execution requirement for a verifier.