QODIQA Implementation Playbook
for Deterministic Runtime Consent Enforcement

#Executive Technical Overview

The QODIQA Core Standard defines what must be enforced: consent tokens govern all inference-time data processing; enforcement is deterministic and fail-closed; revocation propagates within defined time bounds; and an immutable audit record is produced for every enforcement decision. This Playbook defines how those requirements are realized in infrastructure.

1.1 Purpose of This Playbook

This Playbook is addressed to principal architects, infrastructure engineers, security reviewers, and technical governance leads responsible for implementing deterministic runtime consent enforcement within production systems. Its audience is not policy authors or legal counsel; it is the engineering teams responsible for building and operating the enforcement layer.

1.2 Relationship to the Core Standard

The Core Standard is normative. This Playbook is subordinate. In the event of conflict between this document and the Core Standard, the 68-Point Enforcement Framework, or the QODIQA Whitepaper, those documents prevail. This Playbook may be revised independently to reflect updated deployment practices, provided all revisions maintain strict compliance with Core Standard normative requirements.

1.3 Scope Limitations

This Playbook is scoped strictly to runtime enforcement infrastructure. Pre-deployment consent collection workflows, legal agreement structures, data retention policies, user interface design, model training governance, upstream data provenance, and organizational policy authorship are outside scope unless they directly intersect with enforcement component behavior.

1.4 System Boundary Definition

The QODIQA enforcement boundary begins at the point at which a processing request enters the enforcement perimeter (defined as the first component capable of intercepting and blocking that request) and ends at the point at which an audit record for the corresponding enforcement decision is written to the Audit Ledger in an immutable state. This boundary is a hard system invariant: no processing decision exists within the QODIQA semantics until both conditions are satisfied simultaneously. A PERMIT without a committed AL record is undefined; the system must behave as if no decision occurred.

Any processing that occurs outside these boundaries is not governed by this Playbook and is not considered QODIQA-conformant, regardless of the controls applied to it. The boundary is not a logical construct; it is an operational demarcation that must be verifiable through AL record completeness audit at any point in time.

1.5 Global System Invariants

The following invariants must hold at all times across the entire deployed system, regardless of topology, load condition, or failure state. They are stated as universal propositions against which any operational state may be tested. Violation of any invariant is a conformance failure requiring immediate remediation and forensic audit.

// INV-01: Completeness
∀ inference execution e:
  ∃ audit_record r ∈ AL : r.decision = PERMIT ∧ r.consent_id = e.consent_id
    ∧ r.context_hash = e.context_hash ∧ r.committed_before(e.execution_start)

// INV-02: Fail-Closed
∀ component c ∈ {EG, PE, CR, AL, AE}:
  failure(c) → ∀ requests: decision = DENY

// INV-03: Revocation Propagation Bound
∀ revocation event rev committed at time t:
  ∀ EG instances i: i.cache.state(rev.consent_id) = REVOKED
    within [t, t + TTL]

// INV-04: Artifact Binding
∀ inference execution e:
  e.artifact.context_hash = e.context_hash
    ∧ e.artifact.consent_id = e.consent_id
    ∧ e.artifact.policy_version = e.policy_version
    ∧ verify_hmac(e.artifact) = TRUE

// INV-05: Ledger Monotonicity
∀ records rᵢ, rⱼ ∈ AL: i < j → rᵢ.committed_at < rⱼ.committed_at
  ∧ rⱼ.prev_hash = sha256(rᵢ)

// INV-06: Policy Immutability
∀ policy version pv marked FROZEN:
  ¬∃ mutation m : m.target = pv ∧ m.committed_at > pv.frozen_at

// INV-07: Evaluation Determinism
∀ T, H, P: E(T,H,P) at time t₁ = E(T,H,P) at time t₂
  where policy_version(P) is FROZEN and T.state is identical at t₁ and t₂

#System Architecture Blueprint

A conformant QODIQA enforcement infrastructure requires exactly seven canonical components. Each component has a strictly defined responsibility domain. No component may assume responsibility for a domain assigned to another without explicit interface delegation. The architecture is minimal by design: every component present is necessary; no component present is optional on the enforcement path.

2.1 Component Inventory

2.2 Canonical Architecture Diagram

2.3 Data Flow Model

Every enforcement-bound request traverses a defined sequence of component interactions. The sequence is invariant: no step may be skipped, reordered, or substituted. The data flow model formalizes these interactions as a directed acyclic graph with a single terminal condition per request.

2.4 Failure Isolation

Each component failure mode is defined and bounded. No component failure may produce a PERMIT outcome. Component failures are classified into two categories: blocking failures, which halt the enforcement path and deny all requests; and degraded failures, which reduce observability without affecting enforcement decisions. The Monitoring Layer is the only component with a degraded failure mode; all enforcement-path components have blocking failure modes.

2.5 Failure Cascade Simulation

The following failure cascade simulations define the required system behavior under specific multi-component failure scenarios. Each cascade must be validated during conformance testing. Failure cascade FC-01 through FC-05 are defined below.

// FC-01: CR becomes unavailable during active request processing

State[0]: REQUEST RECEIVED
  EG has validated request fields; consent_id present and well-formed
  EG issues CR query: GET /token/{consent_id}

State[1]: CR TIMEOUT
  CR does not respond within T_CR_ceiling (30ms default)
  EG circuit breaker records failure count +1

State[2]: CIRCUIT EVALUATION
  If failure_count < N (threshold): single-request fail-closed
    → decision = DENY; reason = REGISTRY_UNAVAILABLE
    → AL.append(DENY record)
    → return DENY to caller
  If failure_count ≥ N within window W:
    → circuit OPENS; all subsequent requests denied without CR query
    → ML alert dispatched: CRITICAL — CR circuit breaker OPEN

State[3]: CIRCUIT OPEN BEHAVIOR
  All requests: decision = DENY; reason = CIRCUIT_OPEN
  AL.append(DENY record) for each request
  No inference execution is permitted during circuit-open state
  No requests are queued or deferred; all are immediately denied

State[4]: RECOVERY
  Circuit enters half-open after recovery interval
  Single probe request issued to CR
  If probe succeeds: circuit CLOSES; normal processing resumes
  If probe fails: circuit remains OPEN; recovery interval resets

// FC-02: AL write fails after PERMIT decision

State[0]: PERMIT DECISION REACHED
  PE evaluated E(T,H,P) = PERMIT
  AE generated artifact; artifact is valid
  EG issues AL write: APPEND enforcement_record

State[1]: AL WRITE TIMEOUT OR REJECTION
  AL does not acknowledge write within T_AL_ceiling (20ms)
  OR AL returns error code

State[2]: MANDATORY RESPONSE
  EG MUST NOT release request to inference system
  Decision is BLOCKED; not PERMIT; not DENY
  EG returns HTTP 503 to caller
  AL.append(AUDIT_WRITE_FAILURE record) if AL recovers within 5ms
  ML alert dispatched: CRITICAL — AL write failure

State[3]: RETRY BOUNDARY
  One retry attempt permitted within T_AL_ceiling + 5ms
  If retry succeeds: AL write acknowledged; normal PERMIT path continues
  If retry fails: request is terminated; DENY returned to caller

// Invariant: No inference execution begins without committed AL record.
// A PERMIT that cannot be durably recorded is not a valid PERMIT.

// FC-03: Revocation event not acknowledged by all EG instances within TTL/2

State[0]: REVOCATION COMMITTED
  RS receives revocation event for consent_id C at time T_rev
  RS begins propagation to all registered EG instances

State[1]: PROPAGATION MONITORING
  At time T_rev + TTL/2:
    RS checks acknowledgment receipts from all EG instances
    If all acknowledged: propagation complete; no escalation
    If any EG instance unacknowledged: FC-03 condition

State[2]: CONSERVATIVE MODE ACTIVATION
  For unacknowledged EG instance(s):
    All requests referencing consent_id C: DENY
    Reason: REVOCATION_PENDING_CONSERVATIVE
    AL records: DENY with reason=CONSERVATIVE_REVOCATION_MODE
    Conservative mode cannot be lifted by automated system alone

// Recovery Invariant:
  Conservative mode exit requires: cross-region sync confirmed AND
  EG instance acknowledges revocation event AND
  human operator sign-off on propagation resolution log

// FC-03c: Clock Skew Edge Cases
  Token expiry is evaluated against the EG's local monotonic clock.
  If EG clock skew relative to CR-issued timestamps exceeds
  the operator-configured skew_tolerance (max: 30 seconds):
    EG must treat all timestamp comparisons as unreliable
    EG must deny any request where token.expires_at is within
    [now - skew_tolerance, now + skew_tolerance]
  Clock skew exceeding skew_tolerance triggers ML alert: TIME_SKEW_EXCEEDED
  No request may be permitted on the basis of a timestamp comparison
  when clock skew is unresolved.

// FC-04: Multi-region CR consensus disrupted; CR state divergence between regions

State[0]: DIVERGENCE DETECTED
  Region A CR and Region B CR report different states for consent_id C
  Divergence detected by RS cross-region consistency check

State[1]: CONSERVATIVE MODE — ALL REGIONS
  All requests for affected consent_ids: DENY with REVOCATION_PENDING
  AL records: DENY with reason=CONSERVATIVE_REVOCATION_MODE
  Conservative mode cannot be lifted by automated system alone

// Recovery Invariant:
  Conservative mode exit requires: cross-region sync confirmed AND
  Region B CR hash matches Region A CR hash for affected range AND
  human operator sign-off on divergence resolution log

// FC-04c: Clock Skew Edge Cases

  Token expiry is evaluated against the EG's local monotonic clock.
  If EG clock skew relative to CR-issued timestamps exceeds
  the operator-configured skew_tolerance (max: 30 seconds):
    EG must treat all timestamp comparisons as unreliable
    EG must deny any request where token.expires_at is within
    [now - skew_tolerance, now + skew_tolerance]
  Clock skew exceeding skew_tolerance triggers ML alert: TIME_SKEW_EXCEEDED
  No request may be permitted on the basis of a timestamp comparison
  when clock skew is unresolved.

// FC-05: Inference system receives artifact that fails verification

State[0]: ARTIFACT DELIVERED
  AE generated artifact A for request R; AL record committed
  EG released request to inference system with artifact attached

State[1]: INFERENCE SYSTEM ARTIFACT VERIFICATION
  Inference system verifies HMAC of artifact A
  Verification outcome: FAIL
    Possible causes:
      (a) Key rotation in progress; artifact signed with outgoing key;
          inference system only loaded incoming key
      (b) Artifact corruption in transit
      (c) Artifact replay from different request context (context_hash mismatch)
      (d) AE signing key revoked or expired

State[2]: INFERENCE SYSTEM RESPONSE
  Inference system must refuse execution regardless of PERMIT in artifact
  Inference system emits: ARTIFACT_VERIFY_FAIL{artifact_id=A.id, cause=detected}
  Request is terminated; no inference computation begins
  Inference system returns error to upstream caller

State[3]: EG DETECTION AND RESPONSE
  EG receives ARTIFACT_VERIFY_FAIL event from inference system
  EG emits: ARTIFACT_MISMATCH{request_id=R, artifact_id=A.id}
  ML alert dispatched: CRITICAL — artifact integrity failure
  If cause = (a): verify key rotation window; resume if within window
  If cause = (b): infrastructure integrity concern; halt and investigate
  If cause = (c): replay attack suspected; suspend consent_id; full audit
  If cause = (d): AE key management failure; halt AE; human review

// Non-Recovery Conditions:
  Cause (c) confirmed replay: consent_id suspended; full AL audit required;
    human authorization required to restore consent_id processing
  Cause (d) confirmed: AE must not restart until key hierarchy verified by
    out-of-band inspection; all artifacts from affected AE instance re-verified

#Deployment Topologies

Six deployment topologies are defined. Each is a complete, conformant configuration of the seven canonical components. Topologies differ in where components are hosted, which trust boundaries they cross, and what revocation propagation guarantees are achievable. Operators must declare their topology and document the trust assumptions and revocation TTL applicable to that topology.

All seven canonical components (Enforcement Gateway, Policy Engine, Consent Registry, Revocation Service, Audit Ledger, Artifact Engine, and Monitoring Layer) operate as infrastructure surrounding the inference system. The inference system is a passive recipient of enforcement decisions: it receives a signed consent artifact authorizing execution or a denial signal terminating the request. No changes to model weights, serving code, or runtime configuration of the inference system are required or permitted as substitutes for proper enforcement component deployment. This separation is architecturally intentional and must be preserved across all six deployment topologies defined in this section.

3.1 SaaS Control Plane

All seven components are operated by the enforcement provider and exposed to the inference system operator over authenticated HTTPS APIs. The inference operator is the policy author; the SaaS operator manages component availability and enforces SLA commitments against TTL bounds.

3.2 On-Premises Gateway

All seven components are deployed within the operator's own infrastructure. No enforcement traffic traverses an external network boundary. Required where data residency constraints prohibit external control plane communication.

3.3 Hybrid Deployment

EG and PE are deployed on-premises. CR, RS, and AL are operated in a managed cloud environment with strong consistency guarantees. AE may be co-located with EG or with the cloud boundary.

3.4 Edge Enforcement

EG instances are deployed at the network edge, physically proximate to inference compute. PE operates with a locally cached, version-pinned policy snapshot. CR is read-replicated to the edge with revocation invalidation. AL writes propagate to a central ledger store with bounded durability acknowledgment.

3.5 Multi-Region Deployment

All seven components are replicated across geographic regions. CR is operated as a globally consistent store with linearizable read semantics for the revocation flag. AL is replicated with region-level durability. PE uses a globally synchronized, frozen policy snapshot identical across all regions.

Cross-region revocation propagation must complete within the defined TTL regardless of inter-region network conditions. RS must maintain a propagation record per region per revocation event. Unconfirmed propagation after TTL/2 triggers escalation. Eventual consistency is not acceptable for revocation state under any topology.

3.6 Air-Gapped Environment

All components operate within a network boundary with no external connectivity. Policy updates, external revocation events, and ledger exports are transmitted via authenticated offline media under defined transfer protocols. The RS operates as a local broadcast bus; externally-originated revocation events arrive as signed bundles on authenticated media.

#API Integration Model

Five integration patterns are defined for embedding QODIQA enforcement into existing systems. Each pattern addresses a different placement of the enforcement call relative to the inference system's architecture. All patterns are equivalent in enforcement semantics; they differ only in where the EG function is invoked and how enforcement metadata is transported.

4.1 Preflight Decision Call Pattern

The calling system issues a blocking pre-check before initiating inference computation. The caller presents a consent token reference and a frozen context hash; EG returns a deterministic permit or deny before any inference work begins.

// Request
{
  "consent_id":     "cns_a1b2c3d4e5f6",
  "context_hash":   "sha256:9f86d081884c7d659a2feaa0c55ad015",
  "policy_version": "pv_2026-03-01-frozen",
  "caller_id":      "svc_inference_primary",
  "request_nonce":  "nonce_0f1e2d3c4b5a"
}

// Response — PERMIT
{
  "decision":       "PERMIT",
  "artifact_id":    "art_7a8b9c0d1e2f",
  "audit_ref":      "aud_3c4d5e6f7a8b",
  "policy_version": "pv_2026-03-01-frozen",
  "expires_at":     "2026-03-01T12:05:00Z"
}

// Response — DENY
{
  "decision":       "DENY",
  "reason_code":    "TOKEN_REVOKED",
  "audit_ref":      "aud_9b8a7c6d5e4f",
  "policy_version": "pv_2026-03-01-frozen"
}

4.2 Inline Gateway Interception

EG is deployed as a transparent network proxy or sidecar. All traffic to the inference endpoint passes through EG without requiring application-layer modification. Enforcement metadata is carried in defined HTTP headers.

// Inbound — required on all inference-bound requests
X-QODIQA-Consent-ID:      cns_a1b2c3d4e5f6
X-QODIQA-Context-Hash:    sha256:9f86d081884c7d659a2feaa0c55ad015
X-QODIQA-Policy-Version:  pv_2026-03-01-frozen
X-QODIQA-Request-Nonce:   nonce_0f1e2d3c4b5a

// EG forwards on PERMIT with artifact headers
X-QODIQA-Artifact-ID:     art_7a8b9c0d1e2f
X-QODIQA-Audit-Ref:       aud_3c4d5e6f7a8b

// EG returns HTTP 403 on DENY
{
  "error": "QODIQA_DENY",
  "reason_code": "POLICY_NOT_SATISFIED",
  "audit_ref": "aud_9b8a7c6d5e4f"
}

4.3 SDK Wrapper Pattern

The SDK wraps the inference system's native call interface. Application code calls the SDK's enforcement-aware wrapper; the SDK handles preflight, artifact attachment, and audit propagation transparently. The inference system's native interface is never called directly by application code in a conformant deployment.

function enforced_infer(consent_id, context, payload):
    ctx_hash = sha256_canonical(freeze(context))
    decision = qodiqa_client.preflight(
        consent_id, ctx_hash, POLICY_VERSION
    )
    if decision.status != "PERMIT":
        raise QodiqaDenyError(decision.reason_code, decision.audit_ref)

    result = inference_backend.call(
        payload,
        artifact_id=decision.artifact_id
    )
    qodiqa_client.emit_audit(
        decision.audit_ref,
        outcome="EXECUTED",
        output_hash=sha256_canonical(result)
    )
    return result

4.4 Service Mesh Filter Pattern

An Envoy or compatible L7 filter intercepts inference-bound traffic at the sidecar proxy layer. The filter implements the EG function inline, calling PE and CR via gRPC before forwarding or rejecting the request.

filter:
  name:  qodiqa.enforcement.v1
  type:  HTTP
  phase: REQUEST
  rules:
    - match:
        path_prefix: /v1/inference/
      action:
        call_external:
          endpoint:    qodiqa-pe.enforcement.svc:9090
          method:      POST /evaluate
          timeout_ms:  50
          on_timeout:  DENY
          on_error:    DENY
          forward_headers:
            - X-QODIQA-Consent-ID
            - X-QODIQA-Context-Hash
            - X-QODIQA-Policy-Version

4.5 Agent-Based Orchestration Hook

In multi-agent orchestration systems, enforcement is applied at the point where an individual agent receives a task context and prepares to invoke an inference operation. Each agent call requires an independent enforcement decision; parent-to-subagent delegation does not propagate PERMIT decisions.

4.6 Artifact Propagation and Error Taxonomy

X-QODIQA-Artifact-ID:       art_7a8b9c0d1e2f
X-QODIQA-Artifact-Sig:      base64url(HMAC-SHA256(payload, signing_key))
X-QODIQA-Artifact-Issued:   2026-03-01T12:00:00Z
X-QODIQA-Artifact-Expires:  2026-03-01T12:05:00Z
X-QODIQA-Policy-Binding:    pv_2026-03-01-frozen
X-QODIQA-Consent-Ref:       cns_a1b2c3d4e5f6

#Enforcement Lifecycle: Operational Detail

The enforcement lifecycle comprises seven sequential steps. No step may be skipped. No step may be reordered. The lifecycle is synchronous: execution of the inference request is gated on completion of all seven steps in the defined order.

5.1 Circuit Breaker Behavior

Each downstream component call from EG is wrapped in an independent circuit breaker. State transitions: Closed to Open after N consecutive failures within rolling window W (N ∈ [3,10]; W ∈ [10s,60s], operator-configurable within bounds). Open state: all requests that would have called the failed component are immediately denied. Open to Half-open: probe request after recovery interval; success closes circuit, failure resets interval.

#Performance and Scalability Model

The enforcement path is designed for synchronous, per-request evaluation. The throughput ceiling is determined by the slowest component under load. Optimization is permitted where it does not compromise determinism or fail-closed behavior. Caching is permitted under strict constraints; it does not relax enforcement. All performance specifications in this section are structural bounds derived from component interaction topology, not empirical benchmarks. Operators must not treat these as performance commitments; they must measure and bound their own deployments against these structural models.

6.1 Latency Envelope: Bounded Overhead Model

The enforcement path overhead is the sum of latencies of all synchronous component calls on the critical path. The critical path is the sequence of calls that cannot be parallelized without violating the enforcement ordering invariant. The bounded overhead model is expressed as:

// Critical path — sequential, non-parallelizable
L_enforcement = L_CR + L_PE + L_AE + L_AL + L_EG_overhead

// Where each component latency is bounded:
L_CR  ≤ T_CR_ceiling   (default: 30ms; network-dominated)
L_PE  ≤ T_PE_ceiling   (default: 10ms; CPU-dominated)
L_AE  ≤ T_AE_ceiling   (default:  5ms; crypto-dominated)
L_AL  ≤ T_AL_ceiling   (default: 20ms; durability-dominated)
L_EG_overhead ≤ 3ms    (routing, extraction, circuit check)

// Therefore:
L_enforcement ≤ T_CR + T_PE + T_AE + T_AL + 3ms
             ≤ 30 + 10 + 5 + 20 + 3 = 68ms (no-cache upper bound)

// With CR read cache (warm, valid TTL):
L_enforcement_cached ≤ T_cache_hit + T_PE + T_AE + T_AL + 3ms
                     ≤ 1 + 10 + 5 + 20 + 3 = 39ms

// Hash computation cost — context_hash generation (caller-side):
C_hash(n) = O(n)   where n = byte length of serialized context object
            n is bounded by operator-defined context_max_bytes
            All hash computations must complete in O(n) time;
            no hash function with super-linear behavior is conformant.

// Per-request overhead as a fraction of inference latency:
If L_inference = duration of inference computation
  QODIQA_overhead_fraction = L_enforcement / (L_enforcement + L_inference)
  For L_inference ≥ 200ms: overhead ≤ 25% (no-cache)
  For L_inference ≥ 500ms: overhead ≤ 12% (no-cache)
  Operators with L_inference < 100ms must use cached enforcement path.

6.2 Throughput Envelope

// EG scaling: stateless, linear throughput growth
throughput(EG, n) = n × throughput(EG, 1)
  Invariant: Each EG instance is independent; no shared mutable state
  Load balancer must not route requests to EG instance in circuit-open state

// PE scaling: stateless, linear, policy-snapshot pinned
throughput(PE, n) = n × throughput(PE, 1)
  Invariant: All PE instances must hold the identical frozen policy snapshot
  Policy version deployment must be atomic across all PE instances;
  partial deployment (some PE at v_n, some at v_n+1) is non-conformant

// CR scaling: read-replicas permitted; write linearizability required
read_throughput(CR, n_replicas) ≤ n_replicas × read_throughput(CR, 1)
  Invariant: Revocation flag read must be linearizable; stale-read replicas
  are not acceptable for revocation state without TTL-bounded cache protocol
write_throughput(CR) is bounded by single-primary commit rate
  Adding replicas does not increase write throughput

// AL scaling: partitioned append permitted; addressability invariant holds
throughput(AL, n_partitions) ≤ n_partitions × throughput(AL, 1)
  Invariant: All audit records for a given consent_id must be retrievable
  from a single query interface regardless of partition count
  Hash chain integrity must be verifiable per partition independently

// Cache invalidation determinism:
  cache.invalidate(consent_id) must complete before cache.read(consent_id)
  returns the new state for any subsequent request.
  Invalidation is synchronous. There is no "eventually consistent"
  cache invalidation in a conformant deployment.
  Cost: O(1) per invalidation event per EG instance.
  Total invalidation cost per revocation event:
    O(n_EG_instances) distributed; must complete within TTL.

6.3 Per-Request Overhead

6.4 Caching Constraints

Caching of CR token state is permitted only under three conditions simultaneously: cache entries have a TTL no greater than the configured revocation propagation bound; the cache is invalidated synchronously upon receipt of a revocation event for the cached token; and cache entries for tokens in any state other than ACTIVE must not be cached. PE policy snapshots may be cached indefinitely once frozen; no cache invalidation is required for version-bound PE cache entries.

6.5 Revocation TTL Implications

A shorter revocation TTL reduces the window during which a revoked token might be honored; it increases pressure on CR read consistency and RS propagation infrastructure. Operators must document the deployed revocation TTL and its measurement basis. The TTL is a commitment to affected parties: it defines the maximum exposure window after a revocation event is committed.

6.6 Horizontal Scaling Model

EG and PE are stateless and scale horizontally without coordination. CR scale-out must not relax linearizability for the revocation flag. AL partitioning must ensure all audit records for a given consent_id are addressable from a single query interface. AE scales horizontally in software mode; HSM-backed AE must be over-provisioned relative to peak request rate by a factor of at least 2× to account for HSM transaction jitter.

#Security Hardening Guidelines

7.1 Key Management Model

All cryptographic operations in the enforcement path use keys managed through a three-tier hierarchy. The Root Key is offline, stored in hardware, used only to sign intermediate keys. The Intermediate Signing Key has a maximum 90-day lifetime and derives per-deployment signing keys. The Deployment Signing Key has a maximum 30-day lifetime and is used by AE for artifact HMAC generation.

Key rotation must not interrupt in-flight enforcement; dual-key windows are required during rotation, with both outgoing and incoming keys accepted for artifact verification for the duration of the rotation window. The rotation window must be bounded: its minimum duration is determined by the maximum in-flight request lifetime, defined as the enforcement ceiling (75ms) plus the inference system's maximum processing time. Its maximum duration must not exceed 24 hours. Key rotation events are recorded in AL under record type KEY_ROTATION_EVENT with the outgoing key fingerprint, incoming key fingerprint, and rotation window boundaries.

// KR-INV-01: Dual-key window coverage
∀ artifact A generated at time T during rotation window [T_start, T_end]:
  verify(A, key_outgoing) = TRUE ∨ verify(A, key_incoming) = TRUE

// KR-INV-02: Window boundaries
T_end - T_start ≥ max_in_flight_lifetime (≥ 75ms + max_inference_time)
T_end - T_start ≤ 86400 seconds (24 hours hard ceiling)

// KR-INV-03: Key retirement
After T_end: key_outgoing is no longer accepted for new artifact verification
Before T_start: key_incoming is not accepted for any artifact verification

// KR-INV-04: Audit binding
∀ key rotation event:
  AL.append({type=KEY_ROTATION_EVENT, outgoing_fp, incoming_fp,
             T_start, T_end, authorized_by, root_sig_of_incoming})

// KR-INV-05: No silent rotation
Key rotation without prior AL record is non-conformant.
AE must not accept a new key that has no corresponding AL record.

7.2 Revocation Registry Protection

Write access to the CR revocation flag is restricted to the RS component exclusively. No inference system, application layer, or human operator may set or clear the revocation flag directly. All revocation state changes are logged in AL as a separate record type with issuer attribution. CR must implement write-ahead logging for revocation flag updates; a revocation that is not durably written must not be considered committed.

The write path to the CR revocation flag must be isolated by an authenticated, non-delegable interface. RS must hold the sole cryptographic credential authorized to write to the revocation flag endpoint. This credential must not be derivable from any other credential in the system and must be rotated independently of the AE signing key hierarchy. The revocation write credential must be stored in hardware if available.

7.3 Ledger Integrity and Tamper-Evidence

AL is an append-only store. Deletion and modification operations are disabled at the storage layer. Ledger integrity is verified through a hash chain: each record includes the SHA-256 hash of the previous record in the same partition. The hash chain construction is as follows: for record r_n, r_n.chain_hash = SHA-256(r_(n-1).chain_hash ‖ r_n.content_hash), where content_hash = SHA-256(serialize_canonical(r_n.payload)). The separator ‖ denotes fixed-length concatenation with no ambiguity boundary.

// AL-INV-01: Hash chain continuity
∀ records r_n, r_(n+1) ∈ AL partition P:
  r_(n+1).prev_hash = SHA-256(serialize_canonical(r_n))

// AL-INV-02: Tamper detection procedure
function verify_chain(partition P, range [i, j]):
  computed_hash = hash(r_i)
  for k = i+1 to j:
    if r_k.prev_hash ≠ computed_hash: return CHAIN_BREAK at position k
    computed_hash = hash(r_k)
  return CHAIN_VALID

// AL-INV-03: Export integrity
∀ AL export E:
  E.signature = sign(AL_signing_key, SHA-256(E.content))
  Verifier: ∀ imported exports E: verify(AL_public_key, E.signature) = TRUE

// AL-INV-04: Deletion prohibition — enforced at storage layer
∀ storage operation op on AL:
  op.type ∈ {APPEND} is the only permitted operation
  op.type ∈ {DELETE, UPDATE, TRUNCATE} must be rejected with error code
    OPERATION_PROHIBITED and emitted as ML alert

// AL-INV-05: Integrity heartbeat
  AL verifier runs chain verification on every newly appended record
  at Level 3 (High-Assurance); at minimum weekly at Level 1
  Verification latency: O(records_since_last_verification)
  If verification fails: AL transitions to READ_ONLY mode; writes suspended;
  ML alert: CRITICAL — LEDGER_CHAIN_BREAK; human intervention required

7.4 Secure Enclave Boundary Isolation

Where PE and AE are deployed within hardware secure enclaves (Intel TDX, AMD SEV-SNP, or equivalent), the following boundary isolation requirements apply. The enclave boundary must encompass the entire evaluation function E(T,H,P) and the HMAC signing function; no intermediate evaluation state may be observable outside the enclave boundary. Remote attestation must be performed before any key material is provisioned into the enclave, and attestation must be re-verified after any enclave restart.

The attestation evidence (measurement, signing certificate chain) must be archived in AL at enclave initialization time under record type ENCLAVE_ATTESTATION. If remote attestation fails or is unavailable, the enclave must not accept key provisioning and the enforcement component must not enter operational state. Degraded attestation is not a conformant operational state.

7.5 Abuse Throttling Determinism

EG implements rate limiting at the caller and consent_id dimensions. Per-caller limiting prevents enforcement infrastructure saturation; per-consent_id limiting detects anomalous access patterns on individual tokens. Rate limit exceedance produces a deny decision with reason code RATE_LIMIT_EXCEEDED and an audit record. Rate limiting is an abuse protection layer applied before enforcement evaluation begins; it does not substitute for enforcement.

// RL-INV-01: Rate limit application is pre-enforcement, not post-decision
∀ request R:
  if rate_limit_exceeded(R.caller_id) ∨ rate_limit_exceeded(R.consent_id):
    decision = DENY; reason = RATE_LIMIT_EXCEEDED
    AL.append(deny_record); return DENY
  else: proceed to enforcement path

// RL-INV-02: Rate limit counters are per-EG-instance
  Rate limit state is not shared across EG instances.
  Distributed rate limiting introduces coordination overhead
  that may exceed enforcement latency ceiling.
  Per-instance limits must be set to (global_limit / n_EG_instances)
  where n_EG_instances is the current active instance count.

// RL-INV-03: Rate limit denial is audited
∀ RATE_LIMIT_EXCEEDED denial:
  AL.append({type=DENY, reason=RATE_LIMIT_EXCEEDED,
             consent_id, caller_id, timestamp, limit_dimension})
  No rate-limit denial is silent.

// RL-INV-04: Per-consent_id anomaly detection threshold
  If request_rate(consent_id, window=60s) > anomaly_threshold:
    ML alert: HIGH — CONSENT_ID_ACCESS_ANOMALY{consent_id}
    Enforcement continues; alert is advisory; human review required
    Operator may escalate to automated consent_id suspension
    Automated suspension requires AL record: CONSENT_ID_SUSPENDED

#Determinism Assurance Procedures

8.1 Frozen Context Serialization: Formal Constraints

The context hash presented to the enforcement system must be produced by a canonicalization procedure that yields an identical output for semantically identical inputs regardless of field ordering, whitespace, or encoding differences. The procedure must be deterministic, order-normalized (all map keys sorted lexicographically by UTF-8 byte value), whitespace-stripped, encoding-fixed (UTF-8 throughout, no BOM, no surrogate pairs), and version-tagged (canonicalization algorithm version included in hash prefix). The canonicalization procedure must be published as a versioned, frozen specification; changes to the procedure require a new version identifier and a policy version bump.

// CS-INV-01: Key ordering — lexicographic by UTF-8 byte sequence
∀ map M with keys k₁, k₂: k₁ < k₂ in UTF-8 byte order
  → serialize(M) = "{" k₁ ":" v₁ "," k₂ ":" v₂ "}"

// CS-INV-02: No whitespace in serialized output
∀ serialized S: ¬∃ character c ∈ S: c ∈ {SP, HT, CR, LF}

// CS-INV-03: Encoding fixation
∀ string value v: encode(v) = UTF-8 without BOM
  ¬∃ surrogate pair in encoded output
  All non-ASCII characters must be encoded as UTF-8, not escaped as \uXXXX
  unless the character has no UTF-8 representation

// CS-INV-04: Version prefix
∀ context hash H:
  H = "sha256:qodiqa-ctx-v{N}:" + sha256_hex(serialize(context))
  where N is the canonicalization algorithm version
  H must be treated as opaque by EG; PE does not re-derive H

// CS-INV-05: Semantic equivalence implies hash equality
∀ context objects C₁, C₂: semantically_equal(C₁, C₂)
  → canonical_hash(C₁) = canonical_hash(C₂)
  This invariant must be verified by the determinism test protocol
  using a corpus of semantically-equal but syntactically-distinct inputs.

// CS-INV-06: No floating-point values in context objects
  Floating-point representation is implementation-defined and
  may produce different serializations across platforms.
  ∀ numeric value in context: must be integer or fixed-decimal string.
  Floating-point values must be rejected with error: CONTEXT_TYPE_VIOLATION.

function canonical_hash(context_object):
    normalized = deep_sort_keys(context_object)
    serialized = json_encode(normalized,
        separators=(',', ':'),
        ensure_ascii=False,
        sort_keys=True
    )
    prefix = "qodiqa-ctx-v1:"
    return "sha256:" + sha256_hex(prefix + serialized)

8.2 Policy Version Binding: Proof Model

Every enforcement decision is bound to an explicit, immutable policy version identifier. Policy versions are frozen at publication; a frozen version cannot be modified. The PE rejects evaluation requests referencing a version not present in its local snapshot store. Policy version identifiers follow the structure pv_{ISO-date}-frozen; the -frozen suffix is a normative marker of immutability.

// Definitions
PV = policy version identifier (string, immutable reference)
S(PV) = rule_set bound to PV — a finite, ordered set of evaluation predicates
H(PV) = SHA-256(canonical_serialize(S(PV))) — the policy snapshot hash

// Binding invariant
At freeze time T_freeze:
  S(PV) is finalized; H(PV) computed and published
  AL.append({type=POLICY_FROZEN, pv=PV, snapshot_hash=H(PV), frozen_at=T_freeze})
  PE loads S(PV) and verifies: SHA-256(loaded_rules) = H(PV)
  If verification fails: PE rejects the policy version; emits POLICY_LOAD_FAILURE

// Evaluation binding
∀ evaluation request (T, hash_H, PV):
  PE evaluates E(T, hash_H, PV) using S(PV) loaded and verified at startup
  The evaluation result is bound to PV by construction:
  changing PV changes S(PV) and therefore may change E(T, hash_H, PV)
  No two distinct PVs are permitted to have the same H(PV)
  (uniqueness enforced by date-based identifier and content hash in AL)

// Replay validation logic
∀ replayed request R (same consent_id, context_hash, policy_version, nonce):
  nonce must be unique per request; R.nonce ∉ used_nonces(consent_id)
  If R.nonce ∈ used_nonces: DENY with reason=NONCE_REPLAY_DETECTED
  used_nonces is maintained per EG instance with TTL = token.expires_at
  Replay detection does not prevent legitimate re-evaluation;
  it prevents exact request duplication with identical nonces.

// Frozen context immutability guarantee
∀ context hash H presented to enforcement at time T:
  H is the caller's commitment to the context at T
  The context cannot be modified post-hash without producing a different H
  EG does not re-derive or modify H; it is carried opaquely from caller to PE
  PE does not validate context content; it validates H binds to the decision

8.2a Reproducibility Test Algorithm

procedure VERIFY_DETERMINISM(policy_version PV, corpus_size N ≥ 500):

  Step 1 — Corpus Generation:
    Generate N test vectors (T_i, H_i, PV) with known expected decisions D_i
    Include: edge cases, boundary tokens, expired tokens, revoked tokens,
             unknown issuers, scope mismatches, default-deny cases
    Corpus must be archived with SHA-256 hash before test execution

  Step 2 — First Evaluation Pass:
    For each vector (T_i, H_i, PV):
      result_1[i] = E(T_i, H_i, PV) via live enforcement path
      if result_1[i] ≠ D_i: FAIL — policy_mismatch at vector i
        record failure; terminate; block deployment

  Step 3 — PE Restart:
    Restart all PE instances; verify policy reload: SHA-256(S(PV)) = H(PV)
    If reload verification fails: FAIL — policy snapshot corrupted

  Step 4 — Second Evaluation Pass:
    For each vector (T_i, H_i, PV):
      result_2[i] = E(T_i, H_i, PV) via live enforcement path
      if result_2[i] ≠ result_1[i]: FAIL — non-deterministic evaluation
        record: vector i, result_1[i], result_2[i]; escalate immediately

  Step 5 — Archive:
    If all checks pass:
      AL.append({type=DETERMINISM_TEST, pv=PV, corpus_hash=H(corpus),
                 N=N, pass_rate=1.0, tested_at=now})
      Policy version approved for deployment gate

  Step 6 — Semantic Equivalence Test:
    For a subset of M ≥ 50 vectors: generate semantically-equal variants
    (same context, different field ordering/whitespace)
    Verify canonical_hash produces identical H for each variant pair
    Any variance fails the canonicalization invariant

8.3 Pseudo-Formal Evaluation Model

// Definitions
Let T = token_record = { id, state, issuer, scope, issued_at, expires_at }
Let H = context_hash ∈ SHA256_STRING
Let P = policy_version ∈ FROZEN_POLICY_ID
Let R = rule_set(P) — immutable set of evaluation predicates

// Evaluation function
E(T, H, P) → { PERMIT, DENY } × reason_code

E(T, H, P) =
  if T.state ∈ { REVOKED, EXPIRED, NOT_FOUND }:
      return (DENY, token_state_as_reason(T.state))
  if ¬ issuer_recognized(T.issuer, P):
      return (DENY, POLICY_NOT_SATISFIED)
  let matched = { r ∈ R | r.applies(T, H) }
  if ∃ r ∈ matched: r.effect = DENY:
      return (DENY, POLICY_NOT_SATISFIED)
  if ∀ r ∈ R applicable to (T, H): r.effect = PERMIT:
      return (PERMIT, nil)
  return (DENY, POLICY_NOT_SATISFIED)  // default-deny

// Required properties
∀ T, H, P: E(T, H, P) is total and deterministic
∀ T, H, P: E(T, H, P) is pure (no side effects during evaluation)
∀ T₁=T₂, H₁=H₂, P₁=P₂: E(T₁,H₁,P₁) = E(T₂,H₂,P₂)

8.4 Determinism Test Protocol

Prior to production deployment of any policy version, the VERIFY_DETERMINISM procedure defined in §8.2a must be executed in full and results archived in AL under record type DETERMINISM_TEST. The procedure is a deployment gate: no policy version may be activated on any production PE instance without a passing DETERMINISM_TEST record in AL. The archived corpus hash must be verifiable by any conformance auditor with read access to AL. Any deviation from the step-by-step procedure invalidates the test result and requires re-execution.

#Observability and Monitoring

The Monitoring Layer (ML) is a non-blocking observer of the enforcement path. Its failure does not halt enforcement. Its purpose is to detect, classify, and escalate deviations from expected system state before those deviations become enforcement failures. ML must have read access to all component health endpoints; it must not have write access to any enforcement-path component. All ML alerts are classified according to the failure severity taxonomy defined in §9.3.

9.1 Required Metrics

9.2 Alert Thresholds

9.3 Failure Severity Classification

All failure conditions detected by ML are classified into four severity classes. Classification determines the automated response, escalation path, and required audit record. Classification is deterministic: given an observed condition, the class is uniquely determined by the rules below. No condition may be reclassified downward without a committed AL record documenting the basis for reclassification and human authorization.

9.4 Deterministic Drift Classification Matrix

9.5 Artifact Divergence Response Tree

on ARTIFACT_VERIFY_FAIL{artifact_id=A, consent_id=C, cause=X}:

  1. Retrieve AL record for A: confirm PERMIT record exists for C
     If AL record missing → Class 0: AUDIT_INTEGRITY_BREACH; halt

  2. Determine cause X:

     X = KEY_NOT_RECOGNIZED:
       → Check active key rotation window in AL
       If within rotation window and key is outgoing key: RESUME
         (artifact is valid under dual-key window; log and continue)
       If outside rotation window: Class I; AE signing key compromised
         → AE halted; key rotation emergency procedure initiated

     X = CONTEXT_HASH_MISMATCH:
       → artifact.context_hash ≠ request.context_hash
       → Possible replay: check nonce in AL for prior use
       If nonce previously used: Class 0 — REPLAY_ATTACK; suspend consent_id
       If nonce not previously used: Class I — artifact corruption or tampering

     X = CONSENT_ID_MISMATCH:
       → artifact.consent_id ≠ request.consent_id
       → Class 0: AE issued artifact with wrong binding; full AE audit required

     X = HMAC_INVALID:
       → Artifact bit corruption in transit or at rest
       → Class I: infrastructure integrity concern; isolate AE instance; investigate

  3. All Class 0 and Class I outcomes:
     → Suspend affected consent_id(s) immediately
     → AL.append(ENFORCEMENT_SUSPENDED{consent_id=C, reason=X, timestamp})
     → Human authorization required to unsuspend

  4. SLA breach escalation:
     If Class I condition persists > 15 minutes without human acknowledgment:
       → Escalate to organizational governance authority
       → All enforcement for affected deployment suspended automatically

9.6 Integrity Heartbeat Design

The ML integrity heartbeat is a periodic, independent verification of enforcement system consistency. It is not a health check; it is a bounded consistency audit. The heartbeat runs on a defined schedule (minimum interval: 60 seconds; maximum interval: operator-configured per maturity level) and verifies the following invariants in sequence:

• AL chain integrity: verify the most recent N records form an unbroken chain; N is configured as (heartbeat_interval_seconds × peak_decisions_per_second × 1.2)
• Policy snapshot hash: verify all active PE instances report the same policy version and snapshot hash; divergence between instances is a Class I condition
• Revocation sync state: verify all active EG instances acknowledge the most recent revocation event within TTL; any unacknowledged instance triggers Class II escalation
• Circuit breaker states: verify all component circuit breakers report CLOSED; any non-CLOSED state that is not already alerting triggers immediate Class I escalation
• Key rotation window: verify no key rotation window has been open beyond the maximum window duration; breach triggers Class II escalation

The heartbeat result is recorded in ML with timestamp and a pass/fail status for each verification. Heartbeat failures that are not already active alerts are treated as new Class I conditions. A heartbeat that cannot complete within its scheduled interval due to ML load is itself a Class III condition.

#Conformance Readiness Checklist

The following checklist maps to normative controls QCC-01 through QCC-12 in the QODIQA Core Standard. All applicable items must be satisfied before a deployment may be declared conformant at any maturity level. Items marked with a QCC reference are directly normative; items without are implementation readiness criteria derived from this Playbook. For each item, the validation method, evidence artifact, and fail-closed proof requirement are specified. This checklist functions as a certification pre-audit instrument: a deployment that cannot produce the specified evidence artifact for each item is not conformant, regardless of operational behavior.

10.1 Architecture and Component Completeness

• QCC-01.1All seven canonical components (EG, PE, CR, RS, AL, AE, ML) are deployed and operationally independent. Validation: architecture diagram cross-referenced against network topology; each component has a distinct network address and process boundary. Evidence: network topology map signed by infrastructure lead. Fail-closed proof: simultaneous shutdown of inference system component; verify AL record exists for every request processed prior to shutdown.
• QCC-01.2No component shares a process space with the inference system under enforcement. Validation: process isolation audit; no shared PID namespace; container or VM boundary verified. Evidence: runtime process tree snapshot with process-to-component mapping. Fail-closed proof: kill inference process; verify EG, PE, CR, AL remain operational.
• QCC-01.3Inter-component interfaces are mutually authenticated (mTLS or equivalent). Validation: TLS certificate inspection; certificate pinning verification; test with expired certificate. Evidence: certificate chain for each inter-component channel, archived with expiry dates. Fail-closed proof: present expired certificate at EG-CR interface; verify EG denies and emits alert.
• QCC-02.1EG is positioned as the sole enforcement gateway; no bypass path exists to inference system. Validation: network path analysis; verify inference system has no listener reachable without traversing EG. Evidence: network access control list and routing table for inference system host. Fail-closed proof: attempt direct network connection to inference system port from external host; verify blocked.

10.2 Fail-Closed Validation

• QCC-03.1EG verified to deny all requests on CR unavailability. Validation: controlled CR shutdown test; verify 100% of requests denied within circuit open window. Evidence: test execution log with timestamp, request count, DENY count; must show 0 PERMITs. Failure simulation: terminate CR process; send 50 requests; verify all 50 in AL as DENY with CR_UNAVAILABLE.
• QCC-03.2EG verified to deny all requests on PE unavailability. Validation: controlled PE shutdown test. Evidence: test log with 0 PERMITs during PE outage. Failure simulation: kill PE process; send 20 requests; verify all DENY with PE_UNAVAILABLE.
• QCC-03.3EG verified to deny all requests on AL write failure. Validation: AL write fault injection (network partition EG→AL). Evidence: test log confirming no request proceeds when AL write times out. Failure simulation: block AL port; send 10 requests; verify all blocked with AUDIT_COMMIT_FAILURE; verify 0 inference executions.
• QCC-03.4EG verified to deny all requests on AE generation failure. Validation: AE signing failure injection (corrupt AE signing key). Evidence: test log confirming PERMIT path is blocked when AE fails. Failure simulation: revoke AE signing key; send 10 PERMIT-eligible requests; verify all blocked.
• QCC-03.5Timeout ceilings for each component configured within specified bounds. Validation: configuration inspection; verify timeout values against Table 5.1. Evidence: configuration snapshot with timestamp; values must match declared ceilings. Determinism validation: verify timeout-triggered denial produces AL record within 5ms of timeout expiry.
• QCC-03.6Circuit breaker parameters (N, W) configured within specified bounds. Validation: configuration inspection; N ∈ [3,10], W ∈ [10s,60s]. Evidence: configuration snapshot. Fail-closed proof: trigger N consecutive failures within W; verify circuit opens; verify all subsequent requests denied without component query.

10.3 Consent Registry and Revocation

• QCC-04.1CR implements linearizable reads for the revocation flag. Validation: consistency model documentation from CR storage vendor; linearizability guarantee must be explicit, not implied. Evidence: storage system configuration with consistency level set to linearizable/strong. Fail-closed proof: concurrent write (revocation) and read test under load; verify no stale reads observed in 1,000 concurrent read/write trials.
• QCC-04.2CR cache TTL is no greater than the configured revocation propagation bound. Validation: cache configuration inspection; TTL_cache ≤ TTL_revocation. Evidence: cache configuration with TTL values and comparison to revocation TTL. Determinism validation: verify cache expiry triggers CR re-read, not default-permit.
• QCC-04.3CR cache invalidates synchronously on revocation event receipt. Validation: revocation event injection; measure time from event to cache invalidation. Evidence: measurement log with timestamps; invalidation latency must be ≤ 100ms. Fail-closed proof: submit request for recently-revoked consent_id within 200ms of revocation; verify DENY.
• QCC-05.1RS propagates revocation events to all EG instances within documented TTL. Validation: controlled revocation test across all EG instances; measure propagation latency per instance. Evidence: propagation measurement log with per-EG timestamps; all must be ≤ TTL. Failure simulation: network partition one EG from RS; verify conservative mode activates at TTL/2.
• QCC-05.2Unacknowledged propagation events trigger Class II alert at TTL/2. Validation: propagation delay test; withhold RS→EG acknowledgment; verify ML alert at TTL/2. Evidence: ML alert log with timestamp; alert must fire before TTL/2 + 5 seconds. Fail-closed proof: verify conservative mode activates for affected consent_ids simultaneously with alert.

10.4 Audit Ledger Integrity

• QCC-06.1AL is append-only; delete and modify operations disabled at storage layer. Validation: attempt DELETE and UPDATE operations against AL storage endpoint; verify rejection. Evidence: rejection log with error codes OPERATION_PROHIBITED. Fail-closed proof: verify rejection generates ML alert; verify AL integrity metric unchanged after rejection attempt.
• QCC-06.2AL hash chain integrity verified on defined schedule. Validation: verify chain verification tooling operational; verify last run timestamp in ML. Evidence: chain verification run log; must show CHAIN_VALID for all partitions at last execution. Determinism validation method: re-run chain verification independently; result must be identical to archived result.
• QCC-06.3AL exports are cryptographically signed by AL component key. Validation: export a sample AL partition; verify signature against AL public key. Evidence: export file with signature; verification command and result. Fail-closed proof: tamper one byte of export; verify signature verification fails.
• QCC-06.4AL records contain all required fields including token_record_snapshot. Validation: schema validation against required fields for both PERMIT and DENY record types. Evidence: sample records for each type with field-by-field validation. Determinism validation: verify record schema is identical across all AL partitions.

10.5 Determinism and Artifact Integrity

• QCC-07.1AE uses HMAC-SHA256 with key from defined three-tier key hierarchy. Validation: AE key provenance audit; verify signing key traces to intermediate key, which traces to root key signature. Evidence: key certificate chain with root key fingerprint. Fail-closed proof: generate artifact; verify HMAC with published AE public key; verify inference system refuses artifact with tampered HMAC.
• QCC-07.2Artifact fields include all required fields per §4.6 specification. Validation: artifact schema inspection for a sample of ≥ 100 live artifacts. Evidence: field-by-field validation report. Determinism validation: generate artifact for same inputs twice after AE restart; verify bit-identical output for HMAC (same key, same nonce).
• QCC-07.3Inference system performs artifact verification before beginning computation. Validation: send request with malformed artifact; verify inference system refuses before computation begins. Evidence: inference system refusal log with timestamp; must precede any computation metric. Fail-closed proof: remove artifact entirely; verify inference system refuses with MISSING_ARTIFACT.
• QCC-08.1Context canonicalization procedure is documented and version-tagged. Validation: canonicalization specification exists as versioned document; version tag in context hash matches. Evidence: specification document hash; sample context hash with version prefix decoded. Determinism validation: generate context hash for semantically-equivalent inputs with different field ordering; verify identical output.
• QCC-08.2Policy versions are frozen at publication; no post-publication modification possible. Validation: attempt to modify rule in frozen policy version; verify rejection at PE and AL. Evidence: rejection log. Fail-closed proof: verify AL record exists for policy freeze event; verify policy snapshot hash matches AL record hash.
• QCC-08.3Determinism test protocol (§8.2a, VERIFY_DETERMINISM) executed and archived for all deployed policy versions. Validation: AL query for DETERMINISM_TEST records; verify one exists per deployed policy version. Evidence: AL records with corpus hash, test timestamp, pass_rate=1.0. Failure simulation requirement: execute Steps 2 and 4 with one intentionally incorrect expected decision; verify procedure fails and deployment is blocked.

10.6 Security, Observability and Topology

• QCC-09.1Key hierarchy documented; root key is offline. Validation: key management documentation; verify root key has no network-accessible interface. Evidence: hardware storage inventory for root key; last loaded timestamp (must be at key establishment, not recent). Fail-closed proof: verify root key cannot be queried from any network-connected system.
• QCC-09.2Signing key rotation schedule operational within defined bounds. Validation: rotation log in AL; verify KEY_ROTATION_EVENT records within 30-day ceiling. Evidence: AL export of KEY_ROTATION_EVENT records for past 90 days. Fail-closed proof: verify dual-key window is operational during active rotation; submit request during rotation; verify artifact accepted by both keys.
• QCC-10.1All required metrics from Table 9.1 collected and available to ML. Validation: metric endpoint inspection; verify each metric from Table 9.1 is present and updating. Evidence: metric snapshot at two timestamps; verify counter increments for decision metrics. Determinism validation: verify metric labels are consistent and non-ambiguous.
• QCC-10.2All defined alert thresholds from Table 9.2 active and routed to escalation paths. Validation: alert configuration inspection; trigger test alerts; verify delivery. Evidence: alert configuration snapshot; test alert delivery receipt. Fail-closed proof: trigger each Class I condition; verify enforcement suspension within 30 seconds of threshold breach.
• QCC-11.1Agent delegation independence verified; no transitive permit inheritance. Validation: submit request with delegated agent token; verify enforcement re-evaluates independently for each delegation level. Evidence: test log with delegation chain and per-level decision records in AL. Fail-closed proof: revoke intermediate delegation; verify downstream agent requests denied without re-issuing root token.
• QCC-12.1Deployed topology declared; trust assumptions and revocation TTL documented and disclosed to all affected parties. Validation: topology declaration document exists; TTL value disclosed in system documentation. Evidence: signed topology declaration with TTL value and disclosure acknowledgment. Determinism validation: verify declared TTL is the measured TTL; ML revocation propagation histogram P99 must be ≤ declared TTL.

#Implementation Maturity Levels

Three maturity levels are defined for QODIQA enforcement deployments. Each level represents a complete, conformant deployment. Higher levels extend the baseline with additional hardening, availability, and assurance properties. A deployment must fully satisfy its declared level before claiming that level designation. Levels are not cumulative designations; each is a complete, independently auditable configuration. A deployment that satisfies Level 2 in some dimensions but not others is a Level 1 deployment until all Level 2 requirements are met without exception.

Bounded Liveness Statement: Across all three maturity levels, the enforcement path provides bounded liveness under the following preconditions: all enforcement-path components are operational; all component response times are within their configured ceilings; the revocation propagation round-trip completes within TTL; and the AL write acknowledgment is received within its ceiling. If any precondition fails, liveness is forfeited and fail-closed behavior is mandatory. The system does not guarantee liveness under partial failure; it guarantees only the safety property: no inference execution proceeds without a valid, committed enforcement decision. This is a deliberate architectural choice, not a limitation to be optimized away.

Failure Containment Boundary: Each maturity level defines its failure containment boundary: the scope within which a component failure is contained without requiring cross-boundary intervention. At Level 1, the containment boundary is the single deployment; a datacenter failure requires operator action. At Level 2, the boundary is the failure domain; a single failure domain failure is contained by replicated components. At Level 3, the boundary is the region; a regional failure is contained by cross-region consensus with conservative mode activation. In all cases, the safety property (fail-closed) holds within any boundary.

11.1 Deterministic State Transition Model

The enforcement system operates as a deterministic finite state machine at the request level. The following state transition model defines all valid state sequences for a single enforcement request. Transitions not present in this model are prohibited; any system state that cannot be reached by a valid sequence of transitions from the RECEIVED state is an error state requiring investigation.

// States: RECEIVED → {RATE_LIMITED, CR_QUERIED} → ...
// All terminal states produce exactly one AL record.

RECEIVED
    → RATE_LIMITED         [if rate_limit_exceeded]              → DENY-TERMINAL
    → VALIDATION_FAILED    [if request missing required fields]  → DENY-TERMINAL
    → CR_QUERIED           [otherwise]

CR_QUERIED
    → CR_UNAVAILABLE       [timeout or circuit open]             → DENY-TERMINAL
    → CR_UNRECOGNIZED      [invalid signing key on response]     → DENY-TERMINAL
    → TOKEN_REVOKED        [T.state ∈ {REVOKED, EXPIRED}]       → DENY-TERMINAL
    → TOKEN_NOT_FOUND      [T.state = NOT_FOUND]                 → DENY-TERMINAL
    → PE_QUERIED           [T.state = ACTIVE, issuer recognized]

PE_QUERIED
    → PE_UNAVAILABLE       [timeout or circuit open]             → DENY-TERMINAL
    → PE_DENY              [E(T,H,P) = DENY]                    → DENY-TERMINAL
    → AE_REQUESTED         [E(T,H,P) = PERMIT]

AE_REQUESTED
    → AE_UNAVAILABLE       [timeout or signing failure]          → DENY-TERMINAL
    → AL_WRITE_PENDING     [artifact generated]

AL_WRITE_PENDING
    → AL_WRITE_FAILED      [timeout or error; retry exhausted]   → DENY-TERMINAL
    → EXECUTION_RELEASED   [AL write acknowledged]

EXECUTION_RELEASED
    → ARTIFACT_VERIFY_OK   [inference system verifies artifact]  → PERMIT-TERMINAL
    → ARTIFACT_VERIFY_FAIL [inference system rejects artifact]   → FC-05 procedure

DENY-TERMINAL   → AL.append(DENY record); return DENY to caller
PERMIT-TERMINAL → AL.append(PERMIT record already committed); inference proceeds

// Invariant: Each request terminates in exactly one terminal state.
// No request may remain in a non-terminal state beyond the enforcement ceiling.
// A request that has not reached a terminal state after ceiling + 5ms
// is treated as a timeout; EG transitions to DENY-TERMINAL.

#Institutional Closing Statement

This Playbook completes the QODIQA corpus. It does not introduce new obligations. It does not revise the normative framework established by the Core Standard, the 68-Point Enforcement Framework, or the Whitepaper. It translates those obligations into the concrete architectural, operational, and procedural terms required to build infrastructure that satisfies them.

Every design choice in this document reflects fail-closed discipline. Where a specification might have permitted optimistic execution (proceeding on the assumption that enforcement would likely succeed), this Playbook requires verification before execution. The overhead of verification is the cost of determinism. That cost is borne by the infrastructure, not by the persons whose consent is being enforced.

The Audit Ledger is not a logging mechanism. It is the institutional record of every commitment made and kept, or denied, in the enforcement system's operational history. Its integrity is not a performance characteristic; it is a precondition of accountability.

12.1 Corpus Alignment Statement

This Implementation Playbook (QODIQA-IMPL-2026-001 v1.0) is normatively subordinate to and must be read in conjunction with the following corpus documents. In the event of conflict between this Playbook and any of the foregoing, the foregoing documents prevail. This Playbook introduces Annex-grade failure modeling (FC-01 through FC-05), formalized latency envelope expressions, canonical serialization invariants, policy version binding proof sketch, observability drift classification matrix, artifact divergence response tree, integrity heartbeat design, expanded key rotation invariants, ledger tamper-evidence proof logic, and certification pre-audit conformance checklist with validation criteria and evidence requirements. No normative enforcement semantics have been modified.

#Document Status and Classification