This document specifies ADR-SPEC-1.0, the AI Decision Receipt (ADR) standard. An AI Decision Receipt is a structured, cryptographically signed, machine-verifiable record produced by an AI governance system at the moment it evaluates a request to permit or deny an AI-driven operation.
ADR-SPEC-1.0 defines: the required and optional data categories a conforming receipt must contain; the signing and verification conventions that make each receipt independently authenticatable; the batch tamper-evidence mechanism that protects the integrity of the full receipt corpus over time; and the deterministic replay capability that enables historical AI governance decisions to be independently re-evaluated and confirmed.
The specification is vendor-neutral and freely licensable. Its goal is to establish a common artifact format that AI governance platforms, compliance toolchains, and auditors can rely on across organizations and regulatory frameworks.
Regulated organizations deploying AI systems are required to demonstrate, to auditors and regulators, that AI-driven operations were governed by authorized policies at the time they occurred. Existing audit logging practices — writing event records after execution — do not satisfy this requirement. A post-execution log records what happened; it does not constitute evidence that a governance control was applied before the operation ran.
A pre-execution governance architecture that produces signed, replayable receipts closes this gap. ADR-SPEC-1.0 standardizes the receipt artifact so that any organization implementing pre-execution AI governance can produce evidence in a format that is interoperable, independently verifiable, and ready for regulatory examination.
ADR-SPEC-1.0 covers:
ADR-SPEC-1.0 does not prescribe the internal implementation of the governance engine, the policy language, the data storage layer, or the specific JSON field names used in a conforming implementation. Implementors are free to choose field names, serialization conventions, and storage architectures consistent with the normative requirements in this document.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.
| Term | Definition |
|---|---|
| AI Decision Receipt (ADR) | A signed, structured record produced by an AI governance system at the moment it evaluates a request, capturing the decision outcome and the evidence required to verify and replay that decision. |
| Governance surface | A class of AI operation subject to pre-execution policy enforcement. ADR-SPEC-1.0 defines four normative surfaces: MODEL (model invocation), TOOL (tool or plugin execution), MEMORY (context or memory access), and EXPORT (data egress). |
| Decision outcome | The binary result of policy evaluation: ALLOW (the operation is permitted to proceed) or DENY (the operation is blocked before execution). |
| Policy version binding | A cryptographic commitment to the exact compiled policy document that governed a decision, enabling auditors to verify which policy was in effect at any historical decision point. |
| Deterministic evaluation commitment | A cryptographic hash of the evaluation inputs, computed deterministically (RFC 8785 canonical JSON), such that identical inputs always produce the same hash. Enables independent replay verification. |
| Replay bundle | A preserved snapshot, included in the receipt, containing the evaluation inputs, policy state, execution context, and environment state sufficient to re-evaluate the decision and confirm the same outcome. |
| Merkle batch anchor | A reference to the Merkle tree leaf and root corresponding to this receipt in a batch of receipts sealed to WORM-equivalent storage. Provides tamper-evidence at corpus scale. |
| JWKS endpoint | A publicly accessible JSON Web Key Set endpoint (RFC 7517) at which the public key corresponding to the receipt signature can be retrieved for independent verification. |
| Conforming implementation | An AI governance system that produces receipts satisfying all REQUIRED provisions of this specification. |
A conforming ADR MUST contain the data categories defined in this section. Implementors choose field names, nesting, and serialization format consistent with these requirements.
The receipt payload over which the signature is computed MUST be the RFC 8785 canonical JSON serialization of the receipt's normative fields. Field order is deterministic per RFC 8785; any modification to any included field produces a different canonical form and an invalid signature.
The signing key MUST be published at a JWKS endpoint (RFC 7517) accessible without authentication. The receipt MUST include the key identifier (kid) and the JWKS URL sufficient for a verifying party to locate the correct public key.
Any party in possession of a receipt and network access to the JWKS endpoint MUST be able to verify the receipt using only the following steps, without access to the receipt issuer's systems:
A signature verification failure indicates that the receipt has been modified after issuance or that the signing key does not match. Either condition MUST be treated as a verification failure.
Per-receipt signing provides individual record integrity. Merkle batch sealing provides corpus-level integrity: it prevents selective deletion or modification of receipts from a batch without detection.
Conforming implementations MUST group receipts into batches (at minimum daily) and construct a Merkle tree over the batch. Leaf nodes MUST be computed using domain separation (a fixed prefix distinguishing leaf nodes from internal nodes) to prevent second-preimage attacks.
The Merkle root of each sealed batch MUST be written to WORM-equivalent storage (e.g., S3 Object Lock in compliance mode, or equivalent immutable storage) with a retention period not less than the applicable regulatory record retention requirement (minimum 7 years for HIPAA-scoped deployments).
Each receipt MUST include sufficient information (batch identifier, leaf index, Merkle root, and root storage location) to enable an independent party to verify that the receipt is a member of a sealed batch and that the batch root has not been modified.
A conforming implementation MUST support deterministic replay: given a receipt and the corresponding policy version, an independent governance engine implementation MUST be able to re-evaluate the decision and produce the same outcome.
The replay bundle (§3.5) MUST contain all inputs required for this re-evaluation. The deterministic evaluation commitment (§3.4) serves as the verification key: after replay, the re-computed hash of the evaluation inputs MUST match the commitment in the original receipt.
Replay verification is the mechanism by which auditors and regulators confirm that AI governance controls operated as claimed, without relying on the testimony of the system operator.
ADR-SPEC-1.0 defines four normative governance surfaces. Conforming implementations MUST classify each receipt against one of these surfaces.
| Surface | Scope | Examples |
|---|---|---|
| MODEL | Pre-execution governance of AI model invocations — including large language model calls, embedding generation, and inference requests. | Blocking a model invocation that would process data outside policy-authorized scope; enforcing model version constraints. |
| TOOL | Pre-execution governance of tool and plugin executions — including API calls, code execution, database queries, and third-party service invocations triggered by an AI agent. | Blocking a tool call that would write to a protected data store; enforcing execution scope restrictions. |
| MEMORY | Pre-execution governance of AI context and memory access — including retrieval from vector stores, conversation history, and RAG data sources. | Blocking a cross-tenant memory retrieval; enforcing folder-scoped access boundaries. |
| EXPORT | Pre-execution governance of data egress operations — including file exports, report generation, API responses containing sensitive data, and any operation that moves data across a trust boundary. | Blocking export of PHI to an unauthorized endpoint; enforcing minimum-necessary data principles on AI-generated outputs. |
The following mappings establish how a corpus of ADR-SPEC-1.0 conforming receipts satisfies requirements under major regulatory frameworks. These mappings are normative guidance for implementors seeking to demonstrate compliance.
| Framework / Control | Requirement Summary | ADR-SPEC-1.0 Satisfaction |
|---|---|---|
| NIST AI RMF · GV.OV-03 | AI risk and impact awareness | The policy version binding in each receipt (§3.3) provides a per-decision record of which organizational policy governed the AI operation, enabling systematic audit of policy coverage and drift across the AI deployment. |
| NIST AI RMF · GV.MT-02 | Effectiveness of risk treatments is evaluated | The replay bundle (§3.5) and decision outcome (§3.2) together constitute a quantifiable per-decision measurement artifact. Denial-rate metrics, policy drift detection, and live replay demonstrations are all enabled by the preserved evaluation state. |
| NIST AI RMF · MAP.5 | Organizational risk priorities inform AI risk identification | Rule provenance (§3.3) records the organizational rules that triggered each decision. When rules are named after risk priorities, each receipt is direct evidence that those priorities were operationalized at the point of AI decision. |
| NIST AI RMF · MEASURE.2.5 | AI risk metrics and performance data are collected | The deterministic evaluation commitment (§3.4), decision timestamp (§3.2), and Merkle batch anchor (§3.7) together provide tamper-evident structured data points for AI risk metrics programs. Corpus integrity is guaranteed by the batch sealing protocol (§5). |
| SOC 2 · CC6.1 | Logical access controls | DENY receipts provide signed, pre-execution evidence that unauthorized access was blocked before any data was touched. The governance surface classification (§3.2) enables auditors to verify control coverage across all AI operation types. |
| SOC 2 · CC6.2 | Authentication controls | The organizational scope binding (§3.1) and governance surface classification (§3.2) provide per-decision evidence of access boundary enforcement. The signature (§3.6) ensures the receipt itself cannot be forged. |
| SOC 2 · CC7.2 | System monitoring | A corpus of signed receipts provides a continuous, tamper-evident monitoring record of AI system behavior. The deterministic evaluation commitment (§3.4) enables anomaly detection: duplicate commits may indicate replay attacks; unexpected DENY rates indicate policy violations. |
| HIPAA · §164.312(b) | Audit controls | Each receipt is an immutable, independently verifiable audit record of an AI governance decision. The replay bundle (§3.5) enables OCR examiners to reconstruct the exact conditions under which any PHI access decision was made. Merkle-sealed retention (§5.2) satisfies 6-year minimum retention with tamper-evidence. |
An AI governance system is a conforming implementation of ADR-SPEC-1.0 if it satisfies all REQUIRED provisions in §3 through §6 of this specification.
A receipt is a conforming ADR if it contains all data categories defined in §3.1 through §3.7 and its signature can be independently verified per §4.3.
Partial conformance is permitted for systems in transition. Systems implementing §3.1–§3.4 and §3.6 (without the replay bundle or Merkle anchor) SHOULD declare themselves partial conformant and document which sections are not yet implemented.
ADR-SPEC-1.0 is published under the Creative Commons Attribution 4.0 International License (CC BY 4.0). You are free to share, adapt, and incorporate this specification into derivative works — including commercial products, standards submissions, and regulatory guidance — provided that attribution is given to Tailored Tech Works LLC and the canonical URL is cited.
Canonical citation:
Tailored Tech Works LLC. AI Decision Receipt Specification, ADR-SPEC-1.0. June 2026. https://spec.tailoringtechforward.net/adr/v1. CC BY 4.0.
Patent Pending, U.S. | Tailored Tech Works LLC
| Document | Source |
|---|---|
| RFC 2119 — Key Words for Use in RFCs | IETF, March 1997. rfc-editor.org/rfc/rfc2119 |
| RFC 7517 — JSON Web Key (JWK) | IETF, May 2015. rfc-editor.org/rfc/rfc7517 |
| RFC 8785 — JSON Canonicalization Scheme (JCS) | IETF, June 2020. rfc-editor.org/rfc/rfc8785 |
| NIST AI Risk Management Framework (AI RMF 1.0) | NIST AI 100-1, January 2023. doi:10.6028/NIST.AI.100-1 |
| AICPA SOC 2 Trust Services Criteria — CC6, CC7 | AICPA TSC, 2017 (2022 points of focus). aicpa.org |
| HIPAA Security Rule — 45 CFR Part 164 | HHS. hhs.gov/hipaa |
| NIST RMF Practitioner Comment — ADR-SPEC-1.0 as GOVERN Function Reference | spec.tailoredtechworks.net/nist-rmf-comment/ |