QODIQA Reference Architecture
for Deterministic Runtime Consent Enforcement

#Purpose and Scope

The QODIQA corpus defines what must be enforced and how conformance is measured. This Reference Architecture defines the logical structure within which enforcement occurs. It is the structural complement to the normative corpus: where the Core Standard defines required behavior, this document defines the architectural form within which that behavior is realized.

A reference architecture is a vendor-neutral, technology-neutral canonical model. It defines the minimum structural elements, their responsibilities, their relationships, and the invariants that must hold across all of them, regardless of how any individual element is implemented. Implementations may vary in technology, topology, and scale; they may not vary in the structural properties this architecture specifies. AI systems operating without deterministic consent enforcement lack a verifiable enforcement boundary and cannot produce auditable guarantees of consent compliance.

1.1 Relationship to the Core Standard

The Core Standard is normative over enforcement semantics (what decisions are made and when). This Reference Architecture is normative over the structural properties that make those decisions possible (how components are arranged, isolated, and connected). The Core Standard governs the decision function; this architecture governs the decision infrastructure.

1.2 Relationship to the Implementation Playbook

The Implementation Playbook defines how to build a conformant deployment from this architecture. This document defines what must be built. The Playbook is operationally specific; this document is logically abstract. A deployment that satisfies the Playbook necessarily satisfies this architecture; a deployment that satisfies this architecture but not the Playbook may be architecturally valid but operationally non-conformant.

1.3 Relationship to the Security Profile

The Security and Cryptographic Profile defines the cryptographic properties of the key hierarchy, artifact generation, and audit chain integrity. This architecture defines where those cryptographic properties are applied: at which component boundaries, in which directions, and with which isolation requirements. The Security Profile governs the cryptographic specification; this architecture governs the cryptographic topology.

1.4 Non-Product Positioning Statement

#Architectural Principles

Eight architectural principles govern the QODIQA reference architecture. Each is stated as a structural invariant: a property the architecture must satisfy at all times, not a design aspiration. An architecture that violates any of these principles is not a conformant QODIQA architecture, regardless of the correctness of individual components.

#Canonical Component Model

The QODIQA reference architecture defines nine logically separate components. Each component has a distinct responsibility domain, a defined trust boundary, specified inputs and outputs, explicit security assumptions, and a defined failure behavior. No two components may share persistent state. Components may communicate only through defined interfaces; side channels are non-conformant.

#Logical Data Flow Model

The enforcement data flow is strictly sequential. No step may be executed concurrently with a step that depends on its output. No step may be skipped. No step may be reordered. The sequence is the enforcement invariant: any implementation that satisfies this sequence, regardless of the technology used to realize each component, satisfies the structural data flow requirement.

4.1 Pre-Execution Gating Flow

4.2 Decision Artifact Binding

The enforcement artifact is the cryptographic binding between the enforcement decision and the inference execution it authorizes. The artifact is computed over a fixed set of fields that unambiguously identify the enforcement decision: the consent_id that was evaluated, the context_hash that was evaluated against, the policy version that governed the evaluation, the decision outcome, and a single-use nonce that prevents artifact replay. Any execution that does not present a valid artifact for its exact context is structurally unauthorized.

4.3 Write-Before-Execute Invariant

The write-before-execute invariant is the strongest sequencing constraint in the architecture. It states: no inference execution may begin until the EG has received an acknowledged write from the AL for the enforcement decision authorizing that execution. This invariant has no exceptions. A network failure between the AL write and the artifact release means the artifact is not released. A timeout between the AL write and the acknowledgment means the artifact is not released. An AL that acknowledges without actually writing is a structural integrity failure.

4.4 Revocation Propagation Flow

#Trust Boundary Definition

Trust boundaries are structural properties of the architecture, not configuration choices. A boundary defines where trust transitions: where one domain ends and another begins, and what authentication or verification must occur at the crossing. Every component interface is a boundary crossing; no crossing is implicit.

5.1 External Boundary

The external boundary separates the Calling System (and all external agents) from the enforcement perimeter. The sole authorized crossing point is the Enforcement Gateway. No other enforcement component (PE, CR, RS, AE, AL) has a network interface accessible from outside the enforcement perimeter. Any architecture in which PE, CR, or AL is reachable from the external domain is non-conformant regardless of access control configuration.

5.2 Internal Trust Segments

Within the enforcement perimeter, trust is not uniform. Inter-component trust is directional and purpose-bounded. EG trusts CR to return accurate consent state but does not trust CR to make enforcement decisions. PE trusts the EG to provide an authentic enforcement request but does not trust the EG to interpret policy. AL trusts EG to write accurately but does not trust EG to determine what constitutes a complete enforcement record. These directional trust properties must be enforced by design, not by convention.

5.3 Cross-Region Boundary

In multi-region deployments, each region constitutes a distinct enforcement domain. Enforcement decisions are made locally within each region; cross-region communication is limited to consent state synchronization and revocation propagation. A region must be able to enforce correctly, including fail-closed, while cross-region communication is unavailable. Loss of cross-region connectivity triggers conservative mode for affected consent_ids until synchronization is confirmed.

5.4 Registry Synchronization Boundary

The Registry Synchronization Boundary is the interface between CR instances in a replicated deployment. Writes committed at one CR instance must propagate to all CR instances within the declared TTL. The synchronization protocol must preserve linearizability for revocation writes: once a revocation is committed at any CR instance, that instance must not serve a non-revoked state for the affected consent_id, and all other instances must converge to the revoked state within TTL.

5.5 Key Material Isolation Boundary

Key material boundaries define where cryptographic credentials are permitted to exist. The root key must exist only within the offline Trust Anchor. The intermediate key must exist only within HSM-backed storage, never in software or on a general-purpose filesystem. The AE signing key must exist only within the AE signing context, provisioned by the TA over an authenticated channel. No other component may possess, derive, or observe any key material at any tier of the hierarchy. Violation of this boundary nullifies the cryptographic guarantees of the entire enforcement architecture.

#Deployment Topology Variants

The canonical component model supports five reference topology variants. Each variant satisfies the architectural principles and component model defined in this document. The variants differ in how components are distributed, replicated, and isolated across failure domains, not in what the components do or what invariants they must satisfy. All variants enforce identical invariants; topology determines resilience, latency, and failure containment, not enforcement semantics.

#Deterministic Decision Boundary Model

The deterministic decision boundary is the structural isolation that makes QODIQA enforcement verifiable. It is not a quality property of the evaluation logic; it is an architectural constraint on what the evaluation function is permitted to access. The decision function must be a pure function: it produces output from inputs, and nothing else. Any access to state not present in the input tuple corrupts the determinism guarantee.

7.1 Evaluation Isolation

The Policy Engine evaluation function is isolated from all external state at the moment of evaluation. The evaluation is presented with exactly three inputs: the frozen context (including token state as read from CR before the evaluation begins), the frozen policy snapshot (loaded and verified at PE startup), and a representation of the declared policy version. No other information may enter the evaluation function. In particular, the evaluation function must not: make network calls of any kind; read from any mutable shared store; access a real-time clock; generate or consume randomness; or depend on the thread-local state of the evaluation process beyond the input tuple.

7.2 Frozen Context Binding

The frozen context is the canonical, version-tagged serialization of all enforcement-relevant attributes of a request at the moment of EG evaluation. Once the EG has computed the frozen context and its hash, neither the context nor the hash may be modified before delivery to PE. The context_hash delivered to PE by EG is the caller's commitment to a specific context; the PE evaluates that commitment, not the raw request.

// Frozen context: all fields that govern the enforcement decision
// Must be canonically serialized before hashing
// Version prefix ensures hash namespace isolation across schema revisions

frozen_context = {
  "version":        "qodiqa-ctx-v1",
  "consent_id":     "<opaque string>",
  "policy_version": "<declared frozen policy version>",
  "caller_id":      "<authenticated caller identifier>",
  "token_state":    "ACTIVE" | "REVOKED" | "EXPIRED" | "NOT_FOUND",
  "token_scope":    ["scope_a", "scope_b"],  // canonical-sorted
  "issued_at":      1700000000,              // integer seconds
  "expires_at":     1700003600,              // integer seconds; no float
  "nonce":          "<unique per request; not included in context_hash>"
}

// Canonicalization invariants (from Playbook §8.1)
CS-INV-01: Keys sorted lexicographically by UTF-8 byte sequence
CS-INV-02: No whitespace in serialized output
CS-INV-03: UTF-8 encoding, no BOM, no surrogates
CS-INV-04: context_hash = "sha256:qodiqa-ctx-v1:" + hex(SHA256(serialize(context)))
CS-INV-05: Semantic equivalence implies hash equality
CS-INV-06: No floating-point values permitted

7.3 Artifact Generation Atomicity

Artifact generation is an atomic operation from the perspective of the EG. The AE either produces a complete, valid artifact or it produces nothing. There is no partial artifact state observable to EG. If the AE signing operation fails for any reason (key unavailable, hardware fault, signing algorithm rejection of malformed input) the AE returns an error, EG receives no artifact, and the enforcement flow terminates with a DENY decision. EG must not retry signing with a different nonce in response to a signing failure; a new enforcement evaluation must be initiated from the beginning by CS.

7.4 Decision Independence from External Network

At the moment of PE evaluation, the enforcement decision must not depend on any external network call. The token state has already been read from CR by EG and included in the enforcement request. The policy snapshot is already loaded in PE local memory. No additional network access is required or permitted. An implementation that makes external calls during PE evaluation is structurally non-conformant regardless of whether those calls succeed.

• The enforcement decision must not depend on any call to an external service during evaluation
• The enforcement decision must not depend on the current wall clock time; token expiry is checked against the clock before context freezing, not during evaluation
• The enforcement decision must not depend on randomness or entropy from any source
• The enforcement decision must not depend on mutable shared state accessible from multiple PE evaluation threads simultaneously
• The enforcement decision must produce the same result regardless of how many parallel evaluations are in progress in the PE at the same moment

#Scaling and Performance Model

The reference architecture is designed for horizontal scalability of stateless components and vertical or replicated scalability of stateful components. Scalability must not relax enforcement invariants. An architecture that achieves higher throughput by skipping enforcement steps, relaxing audit write guarantees, or introducing eventual consistency into the revocation check path is not a conformant scale-out architecture; it is a non-conformant architecture with increased throughput.

8.1 Horizontal Scaling of Enforcement Gateway

EG instances are structurally stateless at the enforcement decision level. Each EG instance independently maintains its local revocation cache (bounded by the declared TTL), its circuit breaker state (per downstream component), and its rate limit counters (per consent_id, per instance). Because rate limit counters are per-instance, distributed rate limiting is not a structural requirement; per-instance rate limits are a conformant implementation. Multiple EG instances behind a load balancer constitute a horizontally scalable enforcement perimeter with linear throughput scaling.

// EG is stateless at the enforcement decision level
// Each instance independently correct; no coordination required

throughput(EG, n_instances) = n x throughput(EG, 1)   // linear

// Cache invalidation cost: bounded
// On revocation notification: O(1) per EG instance
// Total cost per revocation: O(n_EG_instances)
// Must complete within TTL; provision EG pool size accordingly

// Saturation behavior:
// EG throughput ceiling = min(EG capacity, CR read capacity, AL write capacity)
// Saturation triggers fail-closed, NOT graceful degradation
// Provision all components at ≤ 70% of single-instance ceiling

// Enforcement latency model (no-cache, upper bound):
L_enforcement ≤ L_CR + L_PE + L_AE + L_AL + L_EG_overhead
             ≤ 30  + 10  + 5   + 20  + 3   = 68ms

8.2 Stateless Enforcement Node Properties

EG and PE are structurally stateless enforcement nodes. Statelessness means: no enforcement decision depends on the history of prior decisions on the same instance; adding or removing an instance does not change the enforcement outcome for any specific request; and an instance restart does not require state recovery (beyond snapshot re-verification for PE and fresh CR connectivity for EG). These properties are architectural requirements, not implementation preferences.

8.3 Registry Caching with TTL

EG instances may cache CR query results for the duration of the declared TTL. Caching is a latency optimization, not a semantic change. The cache TTL is identical to the revocation propagation TTL: a consent_id may be served from cache until the cache entry expires, after which a fresh CR query is required. Cache invalidation on revocation notification must complete within the TTL. An EG instance that cannot invalidate a cache entry for a revoked consent_id within TTL must enter conservative mode and deny all requests for that consent_id until CR confirms revocation.

8.4 Ledger Write Throughput Model

The AL is the throughput ceiling of the enforcement system. Every PERMIT and every DENY requires an AL write. The AL write throughput must exceed the enforcement decision rate; otherwise, the enforcement path saturates at the AL and the circuit breaker opens, causing system-wide denial. The AL must be provisioned for the expected peak decision rate with a minimum 40% headroom. AL partitioning by consent_id or by EG instance is a valid scaling strategy; the hash chain must remain verifiable across partition boundaries via the partition-level chain structure defined in the Implementation Playbook.

8.5 Artifact Hashing Cost Envelope

The HMAC-SHA256 computation for artifact generation is O(n) in the byte length of the serialized context. For typical enforcement contexts of 200–500 bytes, this operation completes in microseconds on general-purpose hardware. The cost is bounded and deterministic; it does not depend on the complexity of the policy evaluation or the number of concurrent evaluations. AE throughput scales linearly with the number of AE instances, subject to the signing key being accessible to each instance independently.

#Failure and Degradation Model

The QODIQA reference architecture does not have a graceful degradation mode. Degradation is not a permitted operational state. The architecture has two modes: full enforcement (all components operational, all invariants satisfied) and fail-closed (some components unavailable, all requests denied). Any intermediate state (partial enforcement, selective bypass, or probabilistic enforcement) is structurally non-conformant. Every failure condition described below resolves to one of these two modes.

9.1 Registry Unavailability

9.2 Policy Engine Failure

PE failure is architecturally equivalent to CR failure from the EG perspective: no PE decision can be obtained → no PERMIT can be issued → all requests DENY. PE failure is surfaced by EG as PE_UNAVAILABLE and recorded in AL. PE recovery requires: (a) process restart; (b) snapshot re-load; (c) snapshot hash verification against AL POLICY_FROZEN record; (d) EG circuit breaker probe success. PE may not resume evaluation before all four steps complete. A PE that bypasses snapshot verification during recovery is non-conformant regardless of whether it happens to load the correct snapshot.

9.3 Audit Ledger Failure

AL failure has the most severe impact in the architecture: a PERMIT-eligible request that receives a PERMIT decision from PE and a valid artifact from AE cannot be released because the AL write cannot be committed. The request is denied. The artifact is discarded. The request must be retried by CS from the beginning after AL recovery. Under no circumstances may EG release an artifact without an AL write acknowledgment. An AL that acknowledges writes without durably committing them (acknowledging before fsync, for example) is a silent data integrity failure and is structurally non-conformant at all certification levels.

9.4 Clock Drift Detection

Clock drift affects TTL calculations, token expiry checks, and cross-region timestamp comparisons. The reference architecture defines a maximum clock skew tolerance of 30 seconds between any two enforcement components. If clock skew between an EG instance and its time reference exceeds the tolerance: the EG instance must enter conservative mode, deny all requests where token expiry falls within the skew window, and alert ML with a CLOCK_SKEW_EXCEEDED condition. EG instances must not make enforcement decisions based on timestamps they cannot verify for consistency.

9.5 Key Revocation Event

A key revocation event (distinct from a consent token revocation event) is the retirement of an AE signing key. Key revocation triggers the dual-key window protocol: both the outgoing and incoming keys are valid for artifact verification during the window duration. After the window closes, the outgoing key is retired from all verification contexts. An artifact presented to the inference system after the window closes that was signed by the retired key is no longer valid, regardless of when the original enforcement decision was made. Deployments must ensure that no artifact with a validity period extending beyond the window duration is issued.

9.6 Partial System Partition

A partial system partition is a network condition in which some enforcement components can reach each other but others cannot. Partial partitions are among the most operationally complex failure conditions because they can produce inconsistent behavior across EG instances. The reference architecture handles all partition scenarios through the same mechanism: if a required component is unreachable from EG, the circuit breaker opens for that component at that EG instance, and all requests handled by that EG instance are denied until connectivity is restored. EG instances that can reach all components continue to enforce normally. The partition does not affect enforcement correctness at any individual EG instance; it affects enforcement availability for requests routed to affected EG instances.

#Interoperability and Extensibility Model

The reference architecture is designed for structural stability. Interoperability means that different conformant implementations of the same component can be substituted without affecting enforcement semantics. Extensibility means that new control profiles or audit record types can be added to the architecture without violating existing invariants. Neither interoperability nor extensibility permits relaxation of enforcement invariants or introduction of probabilistic enforcement. This architecture is deployment-agnostic and may be positioned in front of any AI inference system without modification to model internals.

10.1 Version Binding

Every enforcement interaction is bound to an explicit version: the context schema version (embedded in the context_hash prefix), the policy version (referenced in every enforcement request), and the artifact schema version (embedded in the artifact structure). Version binding ensures that a receiver can unambiguously determine the schema under which a context, decision, or artifact was produced. Mixed-version deployments (where different EG instances run different corpus versions) are non-conformant; all instances within a single deployment must run the same corpus version. Version binding is compatible with real-time inference APIs, batch processing systems, streaming inference pipelines, and edge deployments; the binding mechanism is transport-independent.

10.2 Backward Compatibility Handling

Backward compatibility is defined at the interface level. A new version of the corpus that changes the frozen context schema is a breaking change; all components that produce or consume frozen contexts must be updated together. A new version that adds new AL record types is non-breaking; existing components that do not produce the new record types continue to be conformant unless the new record type is declared normatively required. No corpus version may relax enforcement semantics as a backward compatibility measure. The enforcement boundary defined by this architecture applies equivalently to synchronous real-time inference APIs, asynchronous batch processing systems, and streaming inference pipelines; backward compatibility obligations hold across all deployment paradigms.

10.3 Profile Layering

The reference architecture supports two compliance profiles: Core Profile and Full Framework Profile. The Core Profile requires only the controls specified in the Core Standard and the component model defined in this document. The Full Framework Profile additionally requires all 68 controls from the 68-Point Enforcement Framework. Both profiles satisfy all invariants in this architecture; the Full Framework Profile adds additional control surface area above the structural minimum. A deployment may declare conformance at the Core Profile or Full Framework Profile; the claimed profile must be disclosed in the conformance claim.

10.4 Future Control Extension

New control profiles may be defined as annexes to the QODIQA corpus in future revisions. Any new control profile must be additive to the existing architecture: it may require additional component behavior, additional audit record types, or additional test procedures, but it may not modify the enforcement semantics of existing components, relax existing invariants, or introduce probabilistic enforcement. A new control profile that contradicts any invariant in this reference architecture is architecturally incompatible with the QODIQA corpus and cannot be adopted without a corpus version revision.

#Reference Invariants Summary

The following invariants constitute the structural commitments of the QODIQA reference architecture. Each invariant is stated as an unconditional property that any conformant implementation must satisfy. These invariants align with and extend the global system invariants defined in the Implementation Playbook and are the canonical reference for architectural conformance assessment.

#Non-Coverage Disclosure

This Reference Architecture defines the canonical component model, data flows, trust boundaries, and invariants for QODIQA consent enforcement. It does not define everything relevant to a production AI infrastructure deployment. The following domains are explicitly outside the scope of this document and must not be inferred from its contents.

12.1 Product APIs and Protocol Specifications

This document does not define product APIs, wire protocols, message formats beyond what is needed to specify the enforcement flow, or inter-component communication standards. API specification is outside the scope of a reference architecture. Conformant implementations may use any API design, message encoding, or transport protocol that satisfies the structural requirements of this document.

12.2 Specific Technology Stacks

This document does not mandate, recommend, or imply the suitability of any specific technology stack, programming language, database system, message broker, or infrastructure platform for any component. References to architectural properties (linearizability, append-only, distributed consensus) describe requirements, not implementations. Any technology that satisfies the structural requirement is equally valid.

12.3 Enterprise IAM and Identity Systems

This document does not replace, extend, or integrate with enterprise identity and access management systems. The Calling System authenticates to the Enforcement Gateway; the mechanism by which the calling system's identity is established is outside the scope of this architecture. QODIQA enforces consent at the inference boundary, not authentication at organizational or user-identity boundaries. Enterprise IAM and QODIQA serve complementary but structurally distinct functions.

12.4 AI Model Internals

This document does not govern the internal architecture, training process, serving infrastructure, or behavioral properties of AI inference systems. QODIQA enforcement operates at the boundary between the request and the inference system; it does not inspect, modify, or constrain what happens within the inference system. The inference system is treated as a black box that accepts or rejects execution requests based on artifact validity.

12.5 Data Storage Encryption

This document does not define encryption standards for data at rest in any enforcement component. Storage encryption for the Consent Registry, Audit Ledger, or any other component is a deployment-specific security control that must be satisfied according to the applicable regulatory and organizational requirements. This architecture specifies the tamper-evidence properties of the Audit Ledger through hash-chaining; storage encryption is orthogonal to hash-chain integrity and is not specified here.

12.6 Consent Grant Origination

This document does not govern the process by which consent grants are created, the user experience through which data principals express consent, or the legal basis on which consent is established. QODIQA enforcement begins at the point of inference-time enforcement; the processes upstream of consent grant creation (consent collection, consent validity determination, consent storage in authoritative systems of record) are outside the scope of this architecture. The Consent Registry as defined here stores the enforcement-relevant state of consent grants; it is not a system of record for consent governance.

#Institutional Closing Statement

QODIQA is a runtime control plane. It does not govern what AI systems may do in the abstract; it governs what inference executions may occur in specific operational contexts, against specific consent states, evaluated by specific frozen policy versions, at specific instants in time. The architecture defined in this document is the structural form through which that governance is exercised. It is not a description of intent; it is a specification of a runtime boundary.

Determinism is structural in this architecture, not aspirational. The architectural constraint that the PE evaluation function be pure (no network calls, no shared mutable state, no real-time clock, no randomness) is not a performance optimization. It is the mechanism by which enforcement decisions become auditable, replayable, and certifiable. An enforcement system that makes probabilistic or state-dependent decisions cannot be audited; it cannot be replayed; it cannot be certified. Determinism is the precondition for accountability.

13.1 Corpus Alignment Statement

This Reference Architecture (QODIQA-ARCH-2026-001 v1.0) is normatively complementary to and must be read in conjunction with the following corpus documents: QODIQA — Consent as Infrastructure for Artificial Intelligence Technical Whitepaper — Version 1.0; QODIQA — 68-Point Enforcement Framework for Deterministic Runtime Consent Enforcement — Version 1.0; QODIQA — Core Standard for Deterministic Runtime Consent Enforcement — Version 1.0; QODIQA — Implementation Playbook for Deterministic Runtime Consent Enforcement — Version 1.0; QODIQA — Certification Framework for Deterministic Runtime Consent Enforcement — Version 1.0. This document is authoritative for the canonical component model, trust boundary definitions, and architectural invariants. For normative enforcement semantics, defer to the Core Standard. For operational deployment guidance, defer to the Implementation Playbook. For certification procedures, defer to the Certification Framework.

#Document Status and Classification