QODIQA Worked Example
End-to-End Enforcement Scenario

#Scenario Setup

Before tracing the enforcement flow, it is necessary to establish the deployment context, the actors involved, the state of the consent registry at the time of the request, and the active policy version. These are not background details; they are the concrete inputs that QODIQA will consume. Every enforcement decision in this scenario is fully determined by this initial state.

#Intent Declaration

The DecisionRequest is the only input QODIQA accepts. It is a closed, immutable contract: once submitted, none of its fields can be modified, extended, or supplemented. If the application needs to change any field, it must submit a new request. There is no mechanism to amend a request in flight.

QODIQA immediately validates the structural completeness of the request. It verifies that all required fields are present, that no unknown fields have been injected, that the request hash matches the field content, and that the policy_version field references a known, published, and active policy document. This validation is purely structural: QODIQA does not yet know whether the request will be allowed.

#Consent Resolution

QODIQA performs a deterministic lookup against the Consent Registry using three keys derived from the request: data_subject, actor_id, and purpose. The lookup is exact-match only. There is no fuzzy matching, no inheritance from parent records, and no cross-purpose resolution. Either a record exists for this exact combination, or it does not.

If the registry is unavailable — network timeout, service error, or degraded response — QODIQA does not wait and does not retry beyond a single bounded timeout. It issues an immediate fail-closed DENY with reason code E-CONSENT-STORE-UNAVAILABLE and records a failure artifact. This is not an error state requiring manual intervention; it is the correct behavior.

The registry returns record CNST-PT00441-DX-2026. QODIQA now performs four sequential checks. All four must pass; failure at any point terminates consent resolution with DENY.

All four checks pass. QODIQA freezes the consent state as a named reference. This snapshot is immutable: if the patient revokes consent one second later, it will not change the outcome of this evaluation. It will, however, affect the very next request — which is described in Stage 6.

#Policy Evaluation

Policy evaluation in QODIQA is not a reasoning process. The engine does not interpret, infer, or exercise judgment. It evaluates a finite set of declared conditions against a frozen context and produces exactly one outcome. Given the same inputs, it will always produce the same output — this is the determinism guarantee.

The evaluation context is fully captured at the moment evaluation begins. This means the context is impervious to race conditions, concurrent updates, or the passage of time during evaluation. The world that the policy engine sees is the world as it existed at 09:14:32.051Z.

The engine evaluates each policy condition in order. Conditions are stateless predicates. The table below shows the evaluation trace — the complete sequence of conditions tested, the test result for each, and the engine's running state.

Conditions C-01 through C-06 all pass without restriction. Condition C-07 introduces an output restriction. This restriction does not change the top-level outcome from ALLOW; it modifies the terms of the allow. The restriction is encoded into the decision artifact and propagated to the execution layer, which is responsible for enforcing it operationally.

#Decision Artifact Production

The Decision Artifact is the foundational unit of QODIQA's accountability model. It is not a log entry; it is a structured, cryptographically bound record that makes the enforcement decision independently verifiable. Given this artifact and the policy document it references, any auditor can replay the decision and confirm it is correct — without access to the production enforcement system, without access to the Consent Registry, and without any contextual interpretation.

#Execution Gate

QODIQA emits a structured enforcement response to the application tier. The response is minimal: it contains the outcome, the artifact reference, and the restrictions. It does not contain raw data, model outputs, or any content from the clinical record. QODIQA does not touch data; it governs access to it.

The execution layer receives this response and proceeds as follows: it loads patient PT-00441's longitudinal record and lab results from the data store, passes them to dx-assistant-v3 for analysis, intercepts the model output before returning it to Dr. Ionescu's interface, applies deid-filter-v2 to strip any raw patient identifiers from the output, and delivers the filtered result to the clinical interface. The artifact reference DA-20260407-004411 is logged by the execution layer alongside the session record, creating a traceable link between the governance decision and the operational action.

At this point, the happy-path scenario is complete. Total enforcement latency from request submission to decision emission: 21 milliseconds. The patient has not been inconvenienced. Dr. Ionescu has received a de-identified diagnostic analysis. The enforcement decision is permanently recorded and independently verifiable.

#Mid-Session Revocation

#Audit Replay

Three months later, a data protection authority reviewing NeuraPath's AI practices asks: "On April 7th 2026, was patient PT-00441's data accessed by AI systems after she withdrew consent?"

The NeuraPath compliance team runs the following audit query against the decision artifact store:

The query returns zero results. No ALLOW or ALLOW-WITH-RESTRICTIONS artifact exists for patient PT-00441 after 09:22:17.339Z on April 7th. The only artifact in that window is DA-20260407-009972, which is a DENY. The answer to the authority's question is: no — and that answer comes with a cryptographically verifiable artifact, not a human attestation.

The compliance team can additionally replay Decision Artifact DA-20260407-004411 — the authorized request — against the policy document at sha256:f3a1b9...c04d72 and the consent record as it existed at 09:14:32.051Z. The replay will produce the same ALLOW-WITH-RESTRICTIONS outcome. This confirms that the earlier access was correctly authorized under the rules that were in effect at the time.

#What QODIQA Did Not Do

This scenario demonstrates several things QODIQA deliberately chose not to do. Understanding these boundaries is as important as understanding what QODIQA enforces, because the constraints define where implementation responsibility lies in the systems around it.

The intentional minimalism of QODIQA's scope is a design property, not a limitation. A system that tries to do everything provides guarantees about nothing. By restricting itself to enforcement — and doing enforcement deterministically and verifiably — QODIQA makes it possible for every surrounding system to rely on exactly one thing: that if QODIQA said ALLOW, the request was authorized, and if it said DENY, execution did not proceed.

#Document Status and Corpus Alignment