ADR-SPEC-1.0 Open Standard  ·  Technical Brief  ·  Tailored Techworks LLC

Runtime AI Governance Evidence for SOC 2 and HIPAA Audit Cycles: A Practitioner's Implementation Guide Using ADR-SPEC-1.0

Published: June 2026
Spec: ADR-SPEC-1.0
Status: Published
Issuer: Tailored Techworks LLC
Patent Pending: U.S. App. No. 64/029,623
Abstract
AI systems operating in regulated environments generate decisions that auditors cannot currently inspect — there is no deterministic replay, no tamper-evident record, and no mapping to named controls. This brief describes a runtime enforcement architecture that produces machine-verifiable AI Decision Receipts (ADRs) conforming to ADR-SPEC-1.0. Every governed operation — ALLOW or DENY — emits a KMS-signed receipt with a deterministic request hash, a sealed Merkle anchor, and a JWKS-resolvable public key. Each receipt field is mapped here to SOC 2 criteria CC6.1, CC6.2, and CC7.2, and to HIPAA §164.312(b), and the four-surface enforcement model (MODEL · TOOL · MEMORY · EXPORT) is described as the architectural mechanism that closes the gap between "we have AI controls" and "here is the signed evidence."

1. The Evidence Problem

SOC 2 Type II and HIPAA audit cycles increasingly include AI systems in scope, yet the evidence most organizations produce is a combination of policy documents, screenshots, and log exports — none of which satisfies an auditor who asks:

The root cause is architectural: most AI integrations are call-and-response with no enforcement layer. Governance is applied after the fact — in access policies and monitoring dashboards — rather than at the moment of execution. ADR-SPEC-1.0 defines a receipt format that makes governance evidence a first-class output of every AI call.

2. ADR-SPEC-1.0 — AI Decision Receipt Standard

An AI Decision Receipt (ADR) is a structured, cryptographically signed artifact produced for every governed AI operation regardless of outcome. The specification defines:

The JWKS endpoint exposes the signing public key so that any verifying party — auditor tooling, a GRC platform, a counterparty — can verify a receipt signature without contacting the issuer.

3. DenialProof Receipt — Complete Field Map

Every DENY decision produces a DenialProof receipt. The annotated specimen below documents every field in the ADR-SPEC-1.0 schema as implemented in the Fuzentry enforcement runtime. ALLOW decisions produce an equivalent AllowReceipt using the same structure; ruleIds is an empty array when no blocking rule fires.

// ADR-SPEC-1.0 · DenialProof receipt — annotated specimen
{
  "receiptId":        "rcpt_01HXYZ4A7K3P8QTMN2S9W0B6D",       // §3.1  stable UUID v7 — primary audit key
  "specVersion":      "ADR-SPEC-1.0",
  "schema":           "https://spec.tailoredtechworks.net/governance-receipt/v1",

  "decision":         "DENY",                                    // §4.1  ALLOW | DENY | MODIFY
  "surface":          "EXPORT",                                   // §4.2  MODEL | TOOL | MEMORY | EXPORT
  "tenantId":         "acme-corp",                               // JWT-extracted — never trusted from body
  "folderId":         "folder_hipaa-phi-export",

  "intent":           "export-patient-summary",               // §4.3  caller-supplied operation label

  "policyHash":       "sha256:e3b0c44298fc1c149afb4c8996fb924...",  // §5.1  SHA-256 of compiled policy snapshot
  "ruleIds":          ["PHI_EXPORT_BLOCK", "HIPAA_MINIMUM_NECESSARY"],
  "ruleExpressions":  [                                              // §5.3  parallel human-readable reasons
    "dataClassification == 'PHI' AND destination != approvedEHR",
    "requestedFields.length > minimumNecessaryThreshold"
  ],

  "requestHash":      "sha256:9f86d081884c7d659a2feaa0c55ad015...",  // §6.1  deterministic replay key
  "issuedAt":         "2026-06-06T17:00:00.000Z",               // §6.2  ISO-8601 UTC

  "replayInputs": {                                                    // §7    deterministic replay bundle
    "requestInput":     { "patientId": "[sha256-redacted]", "fields": ["diagnosis", "medications"] },
    "policyState":     { "version": "1.4.2", "hash": "sha256:e3b0c4..." },
    "contextState":    { "tenantId": "acme-corp", "folderId": "folder_hipaa-phi-export" },
    "environmentState":{ "timestamp": "2026-06-06T17:00:00.000Z" }
  },

  "signature": {                                                        // §6.3  KMS signature block
    "value":     "base64(KMS RSASSA_PKCS1_V1_5_SHA_256 over RFC-8785 canonical payload)",
    "keyId":     "arn:aws:kms:us-east-1:832923916444:key/mrk-abc123...",
    "algorithm": "RSASSA_PKCS1_V1_5_SHA_256",
    "jwksUri":   "https://api.tailoredtechworks.net/.well-known/adr-jwks.json"
  },

  "merkleAnchor": {                                                     // §8    WORM tamper-evidence chain
    "leafHash":             "sha256:4d7b1c...",
    "merkleRoot":           "sha256:9a1f2e...",
    "sealUri":              "s3://fuzentry-audit-worm/seals/2026/06/06/batch-0001.json",
    "objectLockRetainUntil":"2033-06-06T00:00:00.000Z"               // 7-year retention
  }
}

Field Reference

FieldTypeReq.Description & Audit Significance
receiptIdstring (UUID v7)Required Stable globally unique receipt identifier. Primary key for GRC platform lookups and auditor evidence production.
specVersionstringRequired Always "ADR-SPEC-1.0". Enables parser version-switching as the standard evolves.
decisionALLOW|DENY|MODIFYRequired Governance outcome. The runtime produces a receipt for every decision — ALLOW receipts are as auditable as DENY receipts.
surfaceMODEL|TOOL|MEMORY|EXPORTRequired Enforcement surface intercepted. Maps to CC6.1 control surfaces: MODEL = LLM invocation; EXPORT = data egress; MEMORY = vector-store access; TOOL = function calls.
tenantIdstringRequired Extracted from the JWT at enforcement time — never trusted from the request body. Provides the identity lineage required by CC6.2 and HIPAA minimum-necessary analysis.
folderIdstringOptional Sub-tenant folder scope. Enables per-workload policy isolation; relevant to HIPAA §164.312(b) audit granularity for multi-department deployments.
intentstringRequired Caller-supplied operation label. Appears in auditor evidence narrative alongside policyHash to explain what was attempted.
policyHashsha256:<64-hex>Required SHA-256 of the compiled, immutable policy snapshot active at decision time. Enables independent verification that the correct policy version governed a historical decision.
ruleIdsstring[]Required Names of the rules that fired. For DENY: blocking rules. For ALLOW: empty array. Identifiers appear verbatim in the evidence package alongside the compiled policy defining them.
ruleExpressionsstring[]Required Human-readable parallel array to ruleIds. Provides the plain-language "why" without requiring auditors to parse a policy DSL.
requestHashsha256:<64-hex>Required Deterministic SHA-256 over RFC 8785 canonical JSON of {tenantId, folderId, intent, input}. Identical inputs always produce an identical hash — the cryptographic commitment that enables deterministic replay. CC7.2 monitoring can alert on collision anomalies or unauthorized replay patterns.
issuedAtISO-8601 UTCRequired issuedAt + policyHash together give auditors point-in-time policy binding without retaining the full policy body in every receipt.
replayInputsobjectOptional* Bundle of requestInput, policyState, contextState, environmentState sufficient to deterministically re-evaluate the decision. *Required for SOC 2 evidence when auditors request live replay demonstration.
signature.valuebase64Required KMS RSASSA-PKCS1-v1.5-SHA-256 over the RFC 8785 canonical payload. Any field modification invalidates the signature. Verifiable offline using the JWKS public key.
signature.keyIdKMS ARNRequired Full KMS key ARN — stable across rotation cycles. Used as kid in the JWKS so verifying parties locate the correct public key without out-of-band communication.
signature.jwksUriURIRequired JWKS discovery endpoint. Must be publicly accessible with no authentication per ADR-SPEC-1.0 §6.4.
merkleAnchor.leafHashsha256:<64-hex>Optional* Double-hash of this receipt as a Merkle leaf. *Required for HIPAA and SOC 2 Type II tamper-evident audit trail submissions.
merkleAnchor.merkleRootsha256:<64-hex>Optional* Root of the sealed audit batch. Any modification to any receipt in the batch produces a different root — O(log n) proof size with batch-level tamper detection.
merkleAnchor.sealUriS3 URIOptional* Location of the immutable seal artifact in S3 Object Lock Compliance WORM storage.
merkleAnchor.objectLockRetainUntilISO-8601 UTCOptional* S3 Object Lock Compliance retention deadline. Default 7-year retention (2,557 days) matches SOC 2 and exceeds HIPAA's 6-year requirement.

4. Control Framework Mapping

The following maps ADR-SPEC-1.0 receipt fields to the specific criteria most frequently cited during SOC 2 Type II AI-related control testing and HIPAA §164.312 technical safeguard assessments.

SOC 2 · CC6.1
Logical and Physical Access Controls

The entity implements logical access security software and restricts access to information assets based on authorization requirements.

ADR-SPEC-1.0 Evidence Each receipt binds a decision to an authenticated tenantId (JWT-extracted) and a named surface. The policyHash proves which access rules governed the call. An auditor can query all DENY receipts on the EXPORT surface to demonstrate PHI egress controls were continuously enforced across the audit period, with no gaps in coverage.
SOC 2 · CC6.2
New Access Registration and Authorization

Prior to issuing system credentials, the entity registers and authorizes new internal and external users.

ADR-SPEC-1.0 Evidence Folder-scoped policy (folderId) is provisioned to a tenant before any AI call proceeds. The receipt chain for a new folder begins only after provisioning — the absence of prior receipts is itself evidence of no unauthorized access. The policyHash in the first receipt documents the initial authorization state at onboarding.
SOC 2 · CC7.2
System Monitoring and Anomaly Evaluation

The entity monitors system components and evaluates anomalies to determine whether they represent security events.

ADR-SPEC-1.0 Evidence The deterministic requestHash enables replay-attempt detection: duplicate hashes trigger monitoring alerts. The GEDDE governance trace surfaces drift and correction signals inline. Merkle root mismatches are cryptographic tamper signals. CloudWatch alarms on DENY-rate spikes reference receiptId for direct one-click evidence retrieval.
HIPAA · §164.312(b)
Audit Controls — Technical Safeguard Standard

Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

ADR-SPEC-1.0 Evidence Every AI call touching a PHI-adjacent folder emits a signed receipt regardless of outcome — the "record" requirement is satisfied per-invocation. The ruleIds and ruleExpressions provide the "examine" narrative for each recorded event. The Merkle + S3 Object Lock chain delivers a tamper-evident, WORM-backed audit log that cannot be modified without producing a detectable root mismatch. The 7-year objectLockRetainUntil exceeds HIPAA's 6-year retention floor. The JWKS endpoint enables OCR investigators to independently verify signature authenticity without issuer involvement.

5. Runtime Implementation Architecture

The sequence below describes the production path from an AI API call to a verifiable, sealed receipt. The four-surface model ensures no AI operation bypasses receipt issuance.

  1. Inbound Interception — ExecutionRouter. Every call passes through a single choke-point before execution. The router issues a surface token; no surface (MODEL, TOOL, MEMORY, EXPORT) can proceed without a valid token, eliminating bypass paths that would leave receipt gaps.

  2. Policy Evaluation. The compiled policy snapshot, pinned by policyHash, is evaluated against the request. The DSL compiler content-addresses policies at compile time; runtime evaluation never loads an unpinned version, making policy drift detectable through hash mismatch.

  3. Request Hash Computation. The requestHash is computed over the RFC 8785 canonical form of {tenantId, folderId, intent, input} before the LLM call is made, ensuring the hash covers unmodified pre-execution inputs.

  4. Receipt Construction and KMS Signing. A DecisionReceipt is assembled from the evaluation result and signed with AWS KMS using RSASSA_PKCS1_V1_5_SHA_256 over the RFC 8785 canonical payload. Private key material never leaves KMS hardware. The full KMS ARN is stored as signature.keyId.

  5. DynamoDB Persistence. The signed receipt is written atomically with the enforcement decision to a dedicated table with a 7-year TTL. A receipt either exists or the call did not proceed — there is no code path that executes an AI call without a corresponding receipt write.

  6. Merkle Sealing (Async, Daily). A sealing job reads the prior 24-hour receipt window, builds a Merkle tree with double-hashed leaves and domain separation to prevent second-preimage attacks, and writes the root and full tree to S3 with ObjectLockMode=COMPLIANCE and a 7-year retention date. Each receipt is updated with its merkleAnchor.

  7. JWKS Discovery. The RSA-4096 public key is served at /.well-known/adr-jwks.json with open CORS and a 1-hour cache TTL. No authentication is required. Any verifying party resolves the key by kid matching signature.keyId and verifies the signature without contacting the issuer.

6. Auditor Verification Workflow

A verifying party with a receipt JSON and network access to the JWKS endpoint can independently confirm receipt authenticity in four deterministic steps:

  1. Fetch the JWKSGET https://api.tailoredtechworks.net/.well-known/adr-jwks.json. Locate the key entry whose kid matches the receipt's signature.keyId.
  2. Reconstruct the canonical payload — apply RFC 8785 (JSON Canonicalization Scheme) to the fields specified in ADR-SPEC-1.0 §6.3. Field order is deterministic; any modification produces a different canonical form.
  3. Verify the signature — verify the base64-decoded signature.value against the canonical payload using the RSA public key and RSASSA_PKCS1_V1_5_SHA_256.
  4. Confirm Merkle inclusion — retrieve the seal artifact from merkleAnchor.sealUri, recompute the Merkle path from leafHash to merkleRoot, and confirm the S3 Object Lock response header shows COMPLIANCE mode with a future retention date.
Auditor note: Steps 1–3 require no issuer involvement and no proprietary tooling — only a standard HTTPS client and an RSA verify function available in OpenSSL, Python cryptography, or Node.js crypto. Step 4 requires read access to the WORM bucket, granted under a time-limited cross-account read role scoped to the seal prefix.

7. References

  1. ADR-SPEC-1.0 — AI Decision Receipt Specification, Tailored Techworks LLC (2026). Patent Pending U.S. App. No. 64/029,623.
  2. AICPA Trust Services Criteria — SOC 2, CC6.1 Logical and Physical Access Controls (2017, updated 2022).
  3. AICPA Trust Services Criteria — SOC 2, CC6.2 Registration and Authorization of New Internal and External Users (2017, updated 2022).
  4. AICPA Trust Services Criteria — SOC 2, CC7.2 System Monitoring (2017, updated 2022).
  5. HIPAA Security Rule, 45 CFR §164.312(b) — Audit Controls, Technical Safeguard Standard.
  6. RFC 8785 — JSON Canonicalization Scheme (JCS), IETF, June 2020.
  7. RFC 7517 — JSON Web Key (JWK), IETF, May 2015.
  8. AWS KMS Developer Guide — Asymmetric Keys, RSASSA_PKCS1_V1_5_SHA_256.
  9. AWS S3 Object Lock Documentation — Compliance Mode and WORM Storage.
  10. NIST SP 800-92 — Guide to Computer Security Log Management.