Admissible Automation Standard (AAS)
CTC defines Admissible Automation as a safety property: when automation touches lives and public money, decisions must be replay‑verifiable from machine‑verifiable evidence. If required predicates fail — integrity, freshness, policy drift, missing prerequisites — systems fail closed into HOLD/manual review (or deterministic DENY/PEND where policy defines).
Not replayable → not admissible
The standard converts narrative compliance (“we followed policy”) into machine‑verifiable evidence (“here are the receipts, proofs, and replay outputs”).
Deterministic reason codes
Failures map to stable, enumerable reason codes suitable for procurement scoring and remediation workflows.
Implementation anchors
CTC is written to be implementable — not aspirational.
Stable bytes → stable proofs
Receipts are canonicalized and signed so independent verifiers can recompute identical bytes and digests.
Append‑only anchoring
Receipts are anchored to append‑only heads with inclusion/consistency proofs under freshness bounds.
Independent recomputation
Verifiers reconstruct required structures, recompute metrics, resolve pinned policy artifacts, and reproduce the decision.
Interoperability path (FHIR‑friendly)
The Constitution includes guidance for transporting receipts via FHIR resources (DocumentReference + Provenance + AuditEvent) while preserving canonical bytes for verification.