Standardized Per-Decision AI Governance Records as an Implementation Mechanism for the GOVERN Function

Section 1 — The Evidence Gap in Current AI RMF GOVERN Guidance

The NIST AI Risk Management Framework's GOVERN function correctly identifies organizational policies, measurement programs, and accountability structures as necessary conditions for responsible AI deployment. Functions such as GV.OV-03 (AI risk and impact awareness within the organization) and GV.MT-02 (effectiveness of risk treatments is evaluated and documented) identify what organizations should do. They do not specify what a compliant AI governance decision record must contain, nor how such a record should be independently verified.

This gap has a practical consequence: organizations implementing the RMF today can demonstrate that policies exist and that risk management processes are documented, but they cannot produce a per-decision, machine-verifiable artifact that binds each AI inference to the exact policy version that governed it. Auditors and regulators — whether conducting a SOC 2 review, a HIPAA audit, or an AI-specific regulatory examination — are left with attestations rather than evidence.

The absence of a standardized decision record format creates three downstream problems:

1. Non-comparability. Each organization invents its own log format, making cross-organization or cross-audit consistency impossible.
2. Non-verifiability. Logs without cryptographic binding can be altered after the fact. Auditors cannot distinguish between tampered and authentic records.
3. Non-replayability. Without a deterministic request hash and a preserved policy snapshot, it is not possible to re-evaluate a historical decision to confirm that the same input would produce the same output under the same policy today.

The RMF's MAP and MEASURE functions amplify this gap. MAP.5 requires that organizational risk priorities inform AI risk identification across the enterprise. Without per-decision evidence records, there is no artifact to inspect when determining whether an individual AI decision aligned with the organization's stated risk tolerance at decision time. MEASURE.2.5 requires that AI risk metrics and performance data be collected to evaluate AI trustworthiness. A system that produces no per-decision artifact cannot contribute to this measurement program; aggregate metrics are available, but individual-decision auditability is not.

Section 2 — ADR-SPEC-1.0 as an Implementation Reference

The AI Decision Receipt Specification (ADR-SPEC-1.0) is an open standard that addresses the evidence gap described in Section 1. It defines a vendor-neutral schema, signing conventions, batch Merkle sealing procedures, and a verification interface for AI governance decision records. The specification is designed to be adopted by any AI governance platform, auditor toolchain, or compliance automation system.

The canonical URL for the specification is: https://spec.tailoredtechworks.net/

ADR-SPEC-1.0 is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0) — freely reproducible, adaptable, and redistributable for any purpose, including interoperability implementations. It is vendor-neutral; this comment does not advocate for any commercial product. The specification may be adopted, extended, or incorporated into RMF guidance without restriction.

What ADR-SPEC-1.0 Defines

At its core, ADR-SPEC-1.0 specifies a Decision Receipt — a signed JSON document emitted at the moment an AI governance system evaluates a request. The specification normatively defines:

• Schema. Required and optional data categories covering: a globally unique, immutable record identifier; the governance surface (the class of AI operation evaluated) and the binary decision outcome (permitted or denied); a cryptographic policy version binding (a digest of the exact compiled policy document active at evaluation time); rule provenance (the identifiers and verbatim expressions of the rules that triggered the decision); a deterministic evaluation commitment (a hash of the inputs sufficient to replay the decision exactly); and a temporal commitment (the ISO 8601 UTC timestamp of the evaluation).
• Signing conventions. Asymmetric signature over a RFC 8785 canonical JSON form of the receipt. The corresponding public key is resolved via a JWKS endpoint. The signature is independently verifiable without access to the issuing system or vendor.
• Merkle batch sealing. Individual receipts are anchored into a Merkle tree whose root is published to a WORM-equivalent store. This provides tamper-evidence at batch scale: any alteration to any receipt in a batch causes Merkle root verification to fail.
• Deterministic replay bundle. Each receipt carries a preserved snapshot of the evaluation inputs — the request, the policy state, the execution context, and the environment state at decision time. Identical inputs always produce an identical decision, enabling a historical governance record to be independently re-evaluated to confirm consistent policy application.
• W3C Verifiable Credential envelope. Each receipt can be wrapped in a W3C VC Data Model v1.1 credential issued under a did:web DID with a DataIntegrityProof (ecdsa-2019). This enables governance evidence to be exchanged via DIF credential exchange and OIDC4VP protocols, and presented to any VC-compatible verifier across organizational boundaries — without requiring the receiving party to have access to the issuing governance platform. RFC 3161 timestamp authority tokens (independent of the issuer) can be embedded in the credential proof for time-anchored non-repudiation.
• Verification interface. A four-step verification protocol: retrieve the receipt, fetch the public key from the published JWKS endpoint, reconstruct the canonical payload per the specification, verify the signature. Each step is defined without dependency on the issuing vendor's infrastructure.

This is the artifact that closes the evidence gap identified in Section 1. The complete field-level schema is available at spec.tailoredtechworks.net.

Native OSCAL Output — The NIST-to-NIST Evidence Bridge

ADR-SPEC-1.0 compliant implementations can serialize each governance decision record directly to NIST OSCAL Assessment Results Model v1.0.4 — NIST's own machine-readable compliance format. This creates a direct NIST-to-NIST evidence bridge: AI governance evidence generated under the AI RMF is immediately consumable by OSCAL-based audit toolchains without any intermediate transformation.

Each governance decision maps to an OSCAL Assessment Result Observation. The governance verdict (permitted or denied) maps to an OSCAL Finding with a satisfied or not-satisfied control status. The rule provenance captured in each decision record maps to OSCAL relevant-evidence entries. The Merkle batch anchor — the WORM-stored tamper-evidence root — maps to a linked OSCAL evidence artifact. Compliance framework citations carried in each receipt (SOC 2, HIPAA, EU AI Act) are translated to their NIST SP 800-53 control identifiers and attached as related-controls, enabling native OSCAL control mapping without manual re-tagging.

The OSCAL output is conformant to the NIST-published JSON schema at pages.nist.gov/OSCAL. The resulting documents can be attached to OSCAL System Security Plans (SSPs), submitted as FedRAMP continuous monitoring evidence packages, or consumed by any OSCAL-compatible GRC platform. This is the only AI governance artifact format that natively speaks NIST's own evidence language.

Section 3 — Direct Mapping to NIST AI RMF Functions and Subcategories

The following mappings are drawn from ADR-SPEC-1.0's compliance framework section. Each mapping describes the evidence component within a compliant decision record that satisfies the corresponding RMF subcategory. These mappings demonstrate that per-decision governance records are not an academic construct — they are concrete artifacts that satisfy existing RMF requirements today.

Complete Mapping Table

Section 4 — Recommendation to NIST

We respectfully request that NIST AI RMF supplemental guidance — particularly guidance addressing the GOVERN function's subcategories GV.OV-03 and GV.MT-02, and the MAP.5 and MEASURE.2.5 subcategories — reference standardized per-decision AI governance records as a concrete implementation mechanism.

Specifically, we recommend that the supplemental guidance:

1. Define a "decision record" as a normative construct within RMF GOVERN implementation. The guidance should specify that a compliant AI governance decision record must, at minimum, contain: a unique identifier, a governance decision outcome (ALLOW/DENY), a tamper-evident policy version binding, a deterministic request hash sufficient to enable replay, and a machine-verifiable signature.
2. Reference ADR-SPEC-1.0 as an existing open standard practitioners can adopt today. The specification is vendor-neutral, openly licensed (CC BY 4.0), and has been implemented in production governance environments. Its citation in NIST guidance would accelerate adoption without mandating any specific commercial solution.
3. Require tamper-evidence at batch scale for any compliant decision record corpus. Per-decision signing addresses individual record integrity. Merkle batch sealing — as specified in ADR-SPEC-1.0 — addresses corpus-level integrity: it prevents selective deletion or modification of records from a batch without detection.
4. Specify independent verifiability as a requirement. A governance record that can only be verified by the system that produced it provides limited assurance to external auditors. ADR-SPEC-1.0's JWKS-based signature verification model enables any party with the receipt JSON and network access to the public JWKS endpoint to independently verify the record without engaging the issuing vendor.
5. Acknowledge OSCAL-native AI governance evidence as the interoperability target for GOVERN function implementations. ADR-SPEC-1.0 compliant records serialize directly to NIST OSCAL Assessment Results Model v1.0.4, enabling AI governance evidence to flow natively into FedRAMP continuous monitoring packages, NIST SP 800-53 control evidence submissions, and OSCAL System Security Plan attachments. NIST supplemental guidance that references OSCAL as the recommended delivery format for AI governance decision records would create a complete, end-to-end NIST-native evidence chain — from AI RMF policy to machine-readable OSCAL artifact — with no evidence transformation gap.

On Interoperability

We are not proposing a mandatory standard. We are proposing that NIST guidance acknowledge that the evidence gap exists and point practitioners to a reference implementation. Organizations that have already deployed governance systems generating structured per-decision records can self-assess against ADR-SPEC-1.0. Organizations that have not can use it as a design specification. Auditors can use it as a baseline evidence checklist.

The specification's CC BY 4.0 license explicitly permits incorporation into derivative works, including by NIST. If NIST chooses to develop its own AI Decision Record profile as part of a future RMF supplement, ADR-SPEC-1.0 is offered as a starting point without restriction.

Implementation Precedent

For reference, the architecture described in this comment is currently deployed in production across multi-tenant regulated environments. Each AI governance decision generates an ADR-SPEC-1.0 compliant receipt. Those receipts are sealed into nightly Merkle batches, archived to WORM-equivalent storage, and are independently verifiable via the published JWKS endpoint. DENY-rate metrics, policy-version audit trails, and deterministic replay demonstrations are available on demand to auditors — closing the specific evidence gaps identified in GV.OV-03, GV.MT-02, MAP.5, and MEASURE.2.5.

This is not a future-state proposal. It is a description of what is possible today with existing open standards and available infrastructure.

References