RFC-RGC-1: Receipt Genealogy Chain — Cryptographic Decision Lineage for Governance Receipt Systems: Making Approval Shopping Detectable by Design

RFC-RGC-1 specifies the Receipt Genealogy Chain (RGC) — a governance protocol that links sequential decision receipts for the same asset into a cryptographically verifiable lineage, making the history of decisions leading to any given outcome tamper-evidently reconstructable without database access. RFC-RGC-1 closes the Decision Lineage Gap: the structural absence, in every governance receipt system reviewed (AWS, Azure, Palantir Foundry, Open Policy Agent), of causal linkage between sequential decisions for the same asset. Every existing system answers one question: Was this decision made correctly? RFC-RGC-1 enables a second, categorically different question: How many decisions were made for this asset before this one, and what were they? The core problem RFC-RGC-1 addresses — approval shopping: A governance auditor reviewing an APPROVED receipt cannot determine whether it was the first decision for that asset or whether it followed a sequence of BLOCKED decisions, each submitted with incrementally adjusted signals until one finally passed. The successful approval looks identical to a first-attempt approval when evaluated in isolation. The architectural solution: RFC-RGC-1 embeds five genealogy fields — parentᵣeceiptᵢd, chainᵣootᵢd, generationdepth, chainₖey, and ischainᵣoot — into every receipt payload BEFORE the content hash is computed and the ML-DSA-65 (Dilithium-3, FIPS 204) signature is applied. This architectural position makes genealogy cryptographically bound: removing, altering, or fabricating a receipt's ancestry invalidates the PQC signature. There is no separate table to truncate. There is no audit log to filter. The decision history is in the artifact. Structural consequence — two scenarios, one receipt, distinguishable forever: Scenario A (first-attempt approval): The APPROVED receipt has generationdepth=1 and ischainᵣoot=True. Scenario B (approval after 10 BLOCKs): The APPROVED receipt has generationdepth=11, parentᵣeceiptᵢd pointing to the 10th BLOCKED receipt, and chainᵣootᵢd pointing to the 1st BLOCKED receipt. These fields are covered by the PQC signature and cannot be removed without invalidating it. Decision Lineage Gap — four governance domains addressed: Financial compliance: Pre-trade surveillance detects order parameter manipulation across submissions. Receipt systems without genealogy cannot detect the same pattern in governance evaluations. Insurance and underwriting: Solvency II and NAIC model laws require disclosure consistency. Sequential signal variation across governance evaluations — each producing an independent receipt — is invisible without lineage. Autonomous AI governance: An AI agent operating under governance constraints may probe gates by adjusting action parameters across repeated evaluation cycles. Each cycle produces a valid receipt. The sequence constitutes evidence of adversarial behavior — but only if receipts are linked. Enterprise internal compliance: A decision BLOCKED by senior risk management and subsequently APPROVED after signal modification should be distinguishable from a first-attempt approval by any future auditor, regulator, or counterparty. Regulatory alignment: EU AI Act Art. 9 and Art. 13 require that governance records be sufficient for a competent authority to reconstruct the decision-making process. An audit trail of independent receipts is insufficient when sequential decisions for the same asset occurred. RFC-RGC-1 closes this gap. Additionally: NIST AI RMF (Govern 1. 2), MiCA Art. 30, ISO/IEC 42001: 2023. Reviewed systems — no equivalent mechanism identified: AWS Config Rules / Service Control Policies: each evaluation independent, history requires separate AWS Config query not cryptographically bound to any receipt Azure Policy: compliance history requires Azure Monitor or Activity Log, mutable and not cryptographically embedded Palantir Foundry: audit trail not cryptographically embedded in decision records, requires platform access Open Policy Agent (OPA): no concept of decision receipt, PQC signing, or cross-evaluation lineage Eight formal invariants (RGC-INV-001–008): RGC-INV-001: genealogy ∈ publicₚayload BEFORE hash computation RGC-INV-002: parentᵢd = receiptᵢd (predecessor) for all non-root receipts RGC-INV-003: ∀ R in chain: rootᵢd = receiptᵢd (R₁) RGC-INV-004: depth (R₈+₁) = depth (Rᵢ) + 1 (monotonic increment) RGC-INV-005: chainₖey = f (domain, asset), deterministic RGC-INV-006: root receipt satisfies parent=null, depth=1, isᵣoot=True RGC-INV-007: C₁ ∩ C₂ = ∅ for distinct chain keys (cross-domain isolation) RGC-INV-008: legacy receipts without genealogy continue to verify correctly Security threat model — five attacks, all mitigated: TM-RGC-1 (Parent Erasure) · TM-RGC-2 (Chain Root Fabrication) · TM-RGC-3 (Depth Inflation) · TM-RGC-4 (Cross-Domain Chain Poisoning) · TM-RGC-5 (Buffer Overflow Truncation). Each is formally specified with description, attack surface, impact, mitigation, and residual risk. Standalone verifier: verifyᵣgcₒffline. py — Python 3. 8+, zero internal platform dependencies, 8 checks, exit 0/1, machine-readable JSON output. Adversarial audit: 20/20 PASS across 5 threat categories. Compliance designation: ATF-RGC-Compliant — implementations satisfying RGC-INV-001 through RGC-INV-008 receive this designation regardless of vendor or platform. RFC-RGC-1 is a standalone specification deployable independently of the ATF series. OMNIX QUANTUM LTD · 71-75 Shelton Street, Covent Garden, London WC2H 9JQ, England · standards@omnixquantum. net · omnixquantum. net