Deterministic runtime consent enforcement requires an unambiguous, closed definition of where the system begins, where it ends, which components carry trust, and how that trust is governed. Without explicit boundary definitions, enforcement guarantees cannot be stated, tested, or audited. This document defines the complete system boundary and trust model for the QODIQA architecture. Nine canonical trust zones are established, each with a precisely bounded trust level, enumerated capabilities, prohibited assumptions, and a characterized attack surface. The Enforcement Gateway is defined as the single, non-relocatable, non-delegable enforcement boundary. Rules governing cross-boundary data flows, trust downgrade requirements, containment of untrusted components, and mandatory fail-closed responses are specified without qualification. System invariants are enumerated and referenced throughout the specification. Every statement in this document is normative. Every statement is enforceable, testable, and auditable. Any ambiguity in any boundary or trust definition constitutes a non-compliance condition and invalidates all enforcement guarantees for the affected deployment.
#Executive Definition
Three foundational definitions govern this specification. All subsequent boundary and trust requirements are derived from and constrained by these definitions. Deviation from any definition in an implementation constitutes an immediate non-compliance condition.
The system boundary is the complete, explicit demarcation separating components subject to QODIQA enforcement governance from components that are not. The boundary is defined structurally. A component is inside the boundary if and only if it satisfies every inclusion criterion in Section 2.2. All other components are outside the boundary. No component occupies an intermediate or ambiguous position. Intermediate positions are INVALID.
The trust model is the complete set of explicit trust assignments, trust contracts, trust constraints, and trust revocation rules governing all interactions among all components within and across the system boundary. Trust is NEVER inferred, assumed, or inherited. Every trust relationship MUST be explicitly defined, minimally scoped, cryptographically verifiable where required, and revocable on demand. The default trust assignment for any component not explicitly granted trust is zero.
The enforcement boundary is the single, uniquely defined structural location at which all consent enforcement decisions are made. The enforcement boundary is coincident with the Enforcement Gateway (TZ-4). No enforcement decision may be made outside this location. No inference request may proceed to model execution without traversing this boundary. The enforcement boundary MUST NOT be relocated, duplicated, or bypassed by any conformant implementation.
Definitions 1, 2, and 3 are immutable at runtime. No operational condition, integration requirement, or performance optimization modifies the scope of any definition. An implementation that narrows, broadens, or reinterprets any definition is NON-COMPLIANT.
#System Boundary Definition
The system boundary is fully specified by the four subsections below. Each subsection is normative. Implementations MUST satisfy all four without exception or qualification.
2.1 Formal Boundary Definition
- The Enforcement Gateway (TZ-4) in its entirety, including all enforcement decision logic, request validation routines, and blocking mechanisms.
- The Consent Registry (TZ-5), including all consent state storage, resolution interfaces, and validity verification mechanisms.
- The Policy Engine (TZ-6), including all policy definition storage, version management, and evaluation logic.
- The Audit and Logging Layer (TZ-9), including all decision record generation, tamper-evidence mechanisms, and log integrity verification.
- All cryptographic key management infrastructure used to sign or verify enforcement artifacts, consent tokens, and decision records.
- All inter-component communication channels between the above components, including transport security layers dedicated exclusively to enforcement operations.
- All AI model inference engines, regardless of deployment location or ownership.
- All application layers that submit inference requests to the enforcement gateway.
- All user-controlled interfaces, including consent declaration surfaces, revocation interfaces, and subject-facing portals.
- All external APIs, third-party services, and downstream data consumers that receive outputs of permitted inference operations.
- All infrastructure not enumerated in the inside-boundary list above, including general-purpose compute, storage, and network layers not dedicated exclusively to enforcement operations.
Any component that participates in enforcement-related operations but is not assigned to the inside-boundary enumeration above is operating outside the enforcement boundary. Actions taken by such a component MUST NOT be treated as enforcement decisions. Enforcement claims based on such actions are INVALID.
2.2 Inclusion Criteria
A component is included within the system boundary if and only if ALL of the following conditions are satisfied simultaneously. Satisfaction of a subset is insufficient.
- The component participates directly in the enforcement decision path, the consent resolution path, the policy evaluation path, or the audit record generation path.
- The component is subject to the access controls, integrity requirements, and cryptographic verification requirements specified in the QODIQA Security and Cryptographic Profile.
- The component's behavior is fully deterministic with respect to its inputs. Probabilistic or adaptive behavior disqualifies a component from inclusion.
- The component can be independently audited, and its outputs can be verified against declared inputs.
- The component is operated under a governance configuration satisfying the QODIQA Certification Framework requirements for its functional class.
A component that satisfies some but not all inclusion criteria MUST NOT be assigned to the inside-boundary component set. Partial satisfaction is equivalent to non-satisfaction for boundary assignment purposes.
2.3 Exclusion Criteria
A component is excluded from the system boundary if any one of the following conditions is true. The exclusion criteria are disjunctive; a single positive condition mandates exclusion.
- The component produces probabilistic, stochastic, or adaptive outputs, including but not limited to neural language models, retrieval-augmented generation systems, and reinforcement learning agents.
- The component is controlled, operated, or configurable by an entity that has not obtained QODIQA certification for that component class.
- The component's behavior cannot be fully reproduced from a defined set of inputs without external state dependencies outside the enforcement boundary.
- The component is a user-facing interface through which consent declarations or revocations are submitted.
- The component serves functions unrelated to enforcement, consent resolution, policy evaluation, or audit, even if physically co-located with inside-boundary components.
Any component meeting one or more exclusion criteria that has been placed inside the enforcement boundary introduces an unverified component into the trusted execution environment. All enforcement decisions produced while this condition exists are INVALID. The deployment MUST be suspended pending boundary remediation.
2.4 Boundary Immutability Constraint
- No component may be added to the inside-boundary set without a formal revision of this specification under the QODIQA Governance Charter.
- No runtime condition, operational shortcut, or integration requirement may cause the boundary to expand beyond its defined extent.
- No trust granted to an inside-boundary component may be interpreted as extending to outside-boundary components, regardless of operational proximity or shared infrastructure.
- Implementers MUST document the complete inside-boundary component inventory and maintain it as a controlled artifact under the QODIQA Change Log and Version Control Protocol.
The composition of the inside-boundary component set MUST NOT change at runtime. Any change requires a governed revision of this specification and re-certification of the affected deployment. An undocumented runtime boundary change is a critical security incident.
Any implementation in which the effective enforcement boundary differs from the boundary defined in this document — through expansion, contraction, or ambiguity — is NON-COMPLIANT. Non-compliance invalidates all enforcement guarantees for the affected deployment with immediate effect.
#Canonical Trust Zones
The QODIQA architecture defines exactly nine canonical trust zones. No trust zone other than those defined in this section may be recognized by a conformant implementation. Any component not assignable to one of the nine canonical zones MUST be treated as External Services (TZ-8) with zero trust. Each zone definition is structured as: trust level, capabilities, prohibited assumptions, and attack surface. This structure is uniform across all zones.
Every component interacting with the QODIQA enforcement infrastructure MUST be assigned to exactly one canonical trust zone before any interaction is processed. Unassigned components are PROHIBITED from interacting with any inside-boundary component. A component with ambiguous zone assignment MUST be treated as TZ-8.
- Trust Level
- Zero. All inputs from this zone are treated as adversarial until validated at the enforcement boundary. No elevated trust is granted regardless of claimed user identity or prior session history.
- Capabilities
- Submission of consent declarations and revocations to the Consent Registry (TZ-5) through authenticated channels exclusively. No direct access to TZ-4, TZ-6, TZ-9, or cryptographic key infrastructure.
- Prohibited
- Direct access to the enforcement gateway, policy engine, audit log, or signing key material. Assumption that submitted consent is active without registry confirmation. Inference of prior consent validity.
- Attack Surface
- Consent injection through forged declarations. Replay of previously valid consent after revocation. Scope inflation in consent declaration parameters. Social engineering of consent submission workflows to manufacture broader authorization.
- Trust Level
- Zero. All data and control signals entering from this zone are subjected to full structural and cryptographic validation before any enforcement processing. No exceptions are permitted.
- Capabilities
- Submission of inference requests to the enforcement gateway through the published request interface only. Provision of intent declarations, subject identifiers, and purpose specifications as part of structured request payloads.
- Prohibited
- Assertion of enforcement outcomes. Pre-declaration of consent validity. Provision of policy directives or evaluation instructions. Any attempt to influence enforcement logic through input channel manipulation.
- Attack Surface
- Malformed intent declarations designed to trigger evaluation edge cases or evaluation-logic errors. Purpose field manipulation to obtain permits for non-consented actions. Request flooding to degrade enforcement availability. Injection of structured data mimicking internal enforcement signals to cause misclassification.
- Trust Level
- Zero. The application layer is outside the enforcement boundary. Its correct operation is not assumed. Its claimed identity MUST be verified at the enforcement gateway on every request without exception.
- Capabilities
- Construction and submission of enforcement requests. Receipt of enforcement decisions. Routing of permitted inference requests to model providers upon receipt of a valid, gateway-issued permit token for that specific request.
- Prohibited
- Routing of inference requests to model providers without a valid gateway-issued permit token for that specific request. Caching of permit tokens across requests. Modification of declared intent between gateway submission and permit receipt. Self-assertion of enforcement authority.
- Attack Surface
- Permit token replay across distinct requests. Gateway bypass through direct model provider routing. Permit token fabrication or parameter modification after issuance. Scope extension of permitted actions beyond what the permit specifies. Misrepresentation of requestor identity to obtain permits.
- Trust Level
- Trusted. Trust is contingent on continuous satisfaction of the certification requirements in the QODIQA Certification Framework. Certification lapse immediately reverts TZ-4 to untrusted status.
- Capabilities
- Receipt and full structural validation of inference requests from TZ-2 and TZ-3. Invocation of consent resolution against TZ-5. Invocation of policy evaluation against TZ-6. Issuance of cryptographically signed permit or deny decisions. Generation of decision records to TZ-9. Blocking of all requests for which a valid permit cannot be issued.
- Prohibited
- Delegation of enforcement decisions to any other component. Issuance of conditional or provisional permits. Granting of trust to TZ-7 or TZ-8 components. Processing of requests outside defined input channels. Modification of audit records after generation. Permit issuance when any pre-condition in Section 5 is unconfirmed.
- Attack Surface
- Process integrity compromise enabling silent decision manipulation. Injection of forged consent responses from a compromised TZ-5 component. Policy recommendation tampering from a compromised TZ-6 component. Denial-of-service degradation targeting fail-open behavior. Timing side-channel analysis of decision latency to infer enforcement logic.
No inference request may produce a model output unless a valid, gateway-issued permit token for that specific request exists and has been verified by the forwarding component. This invariant holds without exception under all operational conditions.
- Trust Level
- Conditional. Trusted only for consent state resolution responses that are cryptographically signed and correspond to a registered, non-revoked consent record within its validity window. Unsigned, expired, or unverifiable responses are INVALID and MUST NOT be acted upon.
- Capabilities
- Storage and retrieval of consent records. Verification of consent validity for a specified subject-purpose-scope combination at a specified point in time. Issuance of signed consent validity responses to TZ-4. Receipt of consent revocations from TZ-1 through authenticated interfaces exclusively.
- Prohibited
- Issuance of validity affirmations for revoked consent. Derivation of consent from the absence of explicit revocation. Extension of consent scope beyond declared parameters. Provision of consent validity responses without cryptographic signature.
- Attack Surface
- Tampering with stored consent records to manufacture false consent state. Suppression of revocation records to extend validity of withdrawn consent. Replay of previously valid signed responses after consent expiration. Signing key compromise enabling forged validity affirmations indistinguishable from legitimate ones.
- Trust Level
- Trusted, contingent on verified policy version integrity. The policy engine is trusted only when operating on a policy version whose integrity has been verified against the canonical policy hash registered in the enforcement governance record. An unverified policy version immediately reverts TZ-6 to untrusted status.
- Capabilities
- Evaluation of declared intent and resolved consent state against the active, verified policy version. Production of a binary permit or deny recommendation for TZ-4. Provision of policy evaluation audit metadata including the specific policy version identifier and rule identifiers applied.
- Prohibited
- Production of probabilistic, conditional, or ambiguous recommendations. Evaluation against an unverified or unsigned policy version. Incorporation of runtime state or external signals beyond declared intent and consent resolution inputs. Override of recommendations by any external signal.
- Attack Surface
- Policy content modification to relax enforcement conditions. Policy version substitution to apply outdated or attacker-controlled logic. Evaluation context manipulation to bias decision outcomes. Corruption of the policy hash verification mechanism to suppress detection of tampered policy content.
- Trust Level
- Zero. Model providers are explicitly outside the enforcement boundary. Their outputs carry no enforcement authority. Their internal behavior cannot be verified. Their operation does not constitute enforcement under any characterization.
- Capabilities
- Receipt of inference requests forwarded by TZ-3 upon presentation of a valid, gateway-issued permit token. Generation of inference outputs. No direct interaction with any inside-boundary component is permitted.
- Prohibited
- Receipt of inference requests not accompanied by a valid permit token. Direct communication with TZ-4, TZ-5, TZ-6, or TZ-9. Self-determination of enforcement status. Modification of permit token parameters. Propagation of enforcement claims.
- Attack Surface
- Bypass of gateway enforcement through direct routing by a compromised TZ-3 application layer. Output manipulation to circumvent purpose restrictions applied at policy evaluation. Exfiltration of permit token parameters enabling replay attacks against the enforcement infrastructure. Prompt injection attacks designed to cause the model to generate outputs that impersonate enforcement signals.
- Trust Level
- Zero. All external services, APIs, downstream data consumers, and third-party integrations are untrusted. Any component not explicitly assigned to a defined canonical zone is assigned to this zone by default.
- Capabilities
- Receipt of outputs from permitted inference operations forwarded by TZ-3. No direct access to any inside-boundary component. No capability to initiate interactions with TZ-4, TZ-5, TZ-6, or TZ-9.
- Prohibited
- Direct communication with any inside-boundary component. Provision of signals, configurations, or data that influence enforcement decision logic. Assertion of enforcement status on behalf of the system.
- Attack Surface
- Provision of malicious data to TZ-3 that is subsequently submitted as declared intent to TZ-4. Exfiltration of inference outputs beyond the scope of permitted purposes. Supply chain compromise through external dependencies loaded by inside-boundary components. Data poisoning attacks targeting consent records submitted through TZ-1.
- Trust Level
- Trusted for record generation and integrity verification. Trust is contingent on the tamper-evidence of log storage and the cryptographic integrity of all records. A compromised audit layer does not invalidate enforcement decisions but immediately and completely invalidates all post hoc auditability claims for the period of compromise.
- Capabilities
- Receipt and storage of cryptographically signed enforcement decision records generated by TZ-4. Provision of decision records to authorized auditors upon authenticated request. Verification of record integrity against stored hash values. Detection and flagging of tampering events.
- Prohibited
- Modification of any stored enforcement decision record after generation. Deletion of records within the mandatory retention period. Provision of unsigned or unverified records as valid enforcement evidence. Suppression of decision records under any operational condition including partial failure.
- Attack Surface
- Retroactive record modification to suppress evidence of enforcement bypass. Log truncation or rotation attacks removing records of specific decisions. Injection of false records to manufacture compliance evidence. Audit record exfiltration exposing enforcement patterns that enable targeted bypass.
Every enforcement decision — permit or deny — MUST generate a corresponding audit record in TZ-9 before the decision is communicated to the requesting component. A decision that cannot be audited MUST NOT be issued.
#System Boundary and Trust Architecture
TZ-4 (Enforcement Gateway) is the sole enforcement boundary. All inference requests traverse TZ-4. TZ-5, TZ-6, and TZ-9 are inside-boundary supporting components. All other zones are outside the enforcement boundary.
#Trust Model Definition
The QODIQA trust model is governed by five principles. Each principle is expressed as a rule, a constraint, and a consequence. Compliance with the trust model requires demonstrable adherence to all five principles simultaneously.
4.1 Trust Minimization
Every trust grant MUST be the minimum required for the grantee component to fulfill its defined function. Trust scope MUST NOT exceed the specific capability category for which trust has been granted. Each trust grant MUST be enumerated, scoped, and documented in the implementation's trust inventory.
Trust granted for consent resolution MUST NOT extend to policy evaluation. Trust granted for audit record generation MUST NOT extend to enforcement decision-making. Broad or categorical trust grants are PROHIBITED. Any trust grant that bundles more than one capability category is INVALID.
A component operating with over-broad trust has access to capabilities it has not been authorized to exercise. Any enforcement decision influenced by actions outside the grantee's authorized capability scope is INVALID. The trust inventory MUST be remediated before further enforcement decisions are issued.
4.2 Explicit Trust Contracts
Every trust relationship between components MUST be defined as an explicit trust contract. A trust contract MUST specify: the granting component, the receiving component, the capability scope, the conditions under which trust is active, and the revocation mechanism. Trust contracts MUST exist in written form as part of the implementation's governance documentation.
No trust relationship may exist without a corresponding trust contract. Implicit trust arising from operational proximity, shared infrastructure, or organizational relationships is PROHIBITED. Trust contracts MUST be available for inspection by authorized auditors at any time.
A trust relationship without an explicit contract is an undocumented trust dependency. All enforcement decisions produced under undocumented trust dependencies are INVALID. The affected deployment is NON-COMPLIANT until all trust relationships are backed by explicit contracts.
Every trust relationship active in any enforcement-relevant operation MUST have a corresponding, written trust contract in the governance documentation. An undocumented trust relationship is INVALID regardless of operational duration or organizational familiarity.
4.3 Revocation Requirement
Every trust grant MUST be revocable. Revocation MUST be executable within the time bound defined in the applicable trust contract. Revocation MUST take effect without requiring the consent or cooperation of the component whose trust is being revoked. Implementations MUST define and test the revocation path for every trust contract in their trust inventory.
Trust grants with no defined revocation mechanism are INVALID and MUST NOT be issued. An untestable revocation mechanism is equivalent to no revocation mechanism for compliance purposes.
A non-revocable trust grant cannot be neutralized in response to a security incident. Any deployment containing a non-revocable trust grant is NON-COMPLIANT and cannot assert QODIQA conformance regardless of other properties.
4.4 Verifiability Requirement
Trust MUST be verifiable at the time of each interaction that depends on it. The trusting component MUST confirm, through cryptographic means or a deterministic verification protocol, that the trusted component's current state satisfies the conditions of the trust contract at the moment of interaction.
Trust verified at initialization but not re-verified at interaction time does NOT satisfy this requirement. Session-level trust establishment without per-interaction verification is permitted only where the trust contract explicitly defines the session scope and the session integrity protection mechanism. Unverifiable trust is PROHIBITED.
A trust relationship that cannot be verified at interaction time may be exploited through component compromise between initialization and interaction. Enforcement decisions produced under unverified trust conditions are INVALID. The deployment MUST suspend enforcement operations until verifiability is restored.
4.5 Non-Transitive Trust Rule
Trust MUST NOT propagate across components. A trust grant from component A to component B does not confer any trust from A to any component C, regardless of the relationship between B and C. Every trust relationship MUST be established independently.
The enforcement gateway's trust in TZ-5 MUST NOT be interpreted as trust in any data source that has written to TZ-5. The enforcement gateway's trust in TZ-6 MUST NOT be interpreted as trust in any entity that has contributed to policy authorship. Trust derived by transitivity from any other trust relationship is INVALID.
Transitive trust creates uncontrolled trust chains that allow untrusted entities to influence enforcement outcomes through trusted intermediaries. An implementation relying on transitive trust is structurally incapable of bounding its trust surface and is NON-COMPLIANT.
Trust granted to any component is scoped exclusively to that component and the capabilities enumerated in its trust contract. Trust MUST NOT propagate to any third component through any mechanism, including shared state, shared infrastructure, or API intermediation.
#Enforcement Boundary
The enforcement boundary is the most security-critical structural element in the QODIQA architecture. Its definition is exact, closed, and non-negotiable.
The Deterministic Enforcement Boundary is the Enforcement Gateway (TZ-4). No other component, location, or logical construct constitutes an enforcement boundary in a QODIQA-conformant system. This definition admits no exceptions and no qualifications.
Location
Enforcement occurs exclusively within TZ-4. TZ-4 is the singular, non-delegable decision authority for all consent enforcement outcomes. All inference requests MUST traverse TZ-4 before any interaction with a model provider. No exception to this requirement is permitted under any operational condition.
Why Only There
TZ-4 is the only component simultaneously holding: (1) verified access to consent state via TZ-5, (2) verified access to policy logic via TZ-6, (3) the cryptographic authority to issue binding permit tokens, and (4) the structural position to block requests before model interaction. No other component possesses all four properties. Enforcement attempted at any other location lacks at least one property and is structurally unverifiable.
Impossible Enforcement Locations
- TZ-3 (Application Layer): Untrusted zone. Enforcement logic placed here cannot be audited and is subject to bypass or replacement by the application operator. PROHIBITED.
- TZ-5 (Consent Registry): Consent resolution is a supporting function, not a decision authority. Conflating resolution with enforcement authority creates trust boundary ambiguity. PROHIBITED.
- TZ-6 (Policy Engine): Policy evaluation produces recommendations. Recommendations are not enforcement decisions. Granting decision authority to TZ-6 removes auditability from TZ-4. PROHIBITED.
- TZ-7 (Model Provider): Outside the system boundary and subject to no governance constraint. Self-enforcement by a model provider is PROHIBITED and cannot be recognized as QODIQA-conformant enforcement under any condition.
- TZ-8 (External Services): Zero trust. No enforcement authority can be delegated to a zero-trust zone. PROHIBITED.
- Distributed / Multi-gateway architectures: Multiple enforcement gateways produce no single auditable enforcement record and admit denial of authority in any specific component. PROHIBITED unless each gateway independently satisfies all TZ-4 requirements and each gateway's decisions are independently audited. Shared permit token issuance across gateways is PROHIBITED.
Invalid Architectures
- Any architecture in which TZ-3 can route inference requests to TZ-7 without a TZ-4-issued permit token.
- Any architecture in which TZ-7 accepts inference requests without verifying a valid TZ-4-issued permit token.
- Any architecture in which enforcement decisions are cached and reused across distinct requests.
- Any architecture in which the enforcement gateway can be bypassed by changing network routing configuration without governance approval.
- Any architecture in which the enforcement gateway issues permit tokens without consulting TZ-5 and TZ-6 for each decision.
Pre-Condition Validation
Before issuing any permit decision, TZ-4 MUST verify all of the following. If any cannot be confirmed, TZ-4 MUST issue a deny decision immediately:
- The request is structurally valid and all required fields are present and well-formed.
- The requestor identity is cryptographically authenticated.
- The declared intent is within the processing scope of the enforcement gateway's policy configuration.
- TZ-5 is available and its consent validity response is cryptographically signed and temporally current.
- TZ-6 is available and its recommendation is based on a verified policy version.
Blocking Guarantees
The enforcement gateway MUST implement permit-absence as the default state. A request proceeds only if a permit token has been affirmatively issued for that specific request. Denial is the default. Permitting is the exception that requires positive confirmation of all pre-conditions.
A permit token MUST NOT be issued unless both a signed consent validity affirmation from TZ-5 and a policy permit recommendation from TZ-6 have been received and verified for the specific request being evaluated. Absence of either input MUST result in deny.
Any architectural configuration in which an inference request can reach TZ-7 without traversing TZ-4 is an enforcement bypass condition. An enforcement bypass condition: (1) invalidates all QODIQA conformance claims for the affected deployment with immediate effect; (2) requires immediate system shutdown pending remediation; (3) constitutes a critical security incident requiring governance notification within the timeframe defined in the applicable governance configuration.
#Cross-Boundary Interaction Model
All interactions between components in different trust zones are cross-boundary interactions. Every cross-boundary interaction MUST conform to the rules in this section. Any interaction not explicitly authorized by these rules is PROHIBITED.
6.1 Data Flows
- Data flowing from outside the enforcement boundary into TZ-4 MUST be treated as untrusted and validated in full before processing.
- Data flowing from TZ-5 or TZ-6 to TZ-4 MUST be cryptographically signed by the originating component and verified by TZ-4 before use.
- Data flowing from TZ-4 to outside-boundary components MUST consist only of permit tokens, deny signals, or explicitly authorized audit outputs.
- Data MUST NOT flow directly between TZ-7 or TZ-8 and any inside-boundary component.
- All data crossing the enforcement boundary MUST be logged to TZ-9 as part of the enforcement decision record.
- Data arriving at TZ-4 from an unauthenticated source MUST be rejected immediately without processing.
- Data arriving from TZ-5 or TZ-6 without a valid cryptographic signature MUST be rejected. The pending enforcement decision MUST be converted to deny.
- Data containing fields not defined in the published request schema MUST be rejected. The request MUST NOT proceed.
- Data from TZ-7 or TZ-8 arriving at any inside-boundary component through any channel constitutes an unauthorized data flow and MUST be blocked.
A malformed data flow that is processed rather than rejected introduces unvalidated content into the enforcement trust domain. Any enforcement decision influenced by unvalidated content is INVALID. The malformed interaction MUST be logged as a security event in TZ-9.
6.2 Control Flows
- Control authority flows inward toward TZ-4. No outside-boundary component may issue control instructions to any inside-boundary component.
- TZ-4 may issue control signals to TZ-5 and TZ-6 solely to invoke consent resolution and policy evaluation for a specific enforcement decision.
- TZ-4 MUST NOT delegate control authority to any outside-boundary component under any operational condition.
- Control flow from TZ-1 to TZ-5 for consent registration and revocation is permitted through the authenticated consent submission interface only.
- TZ-3 MUST NOT issue control instructions to TZ-4, TZ-5, TZ-6, or TZ-9.
- TZ-7 and TZ-8 MUST NOT issue any control signals to any component in the architecture.
- TZ-5 and TZ-6 MUST NOT initiate unsolicited interactions with TZ-4.
- Any control signal originating from an outside-boundary component that reaches an inside-boundary component through an unauthorized channel MUST be rejected and logged as a critical security event.
An unauthorized control flow reaching an inside-boundary component constitutes a boundary breach. The affected component MUST reject the signal and generate a critical audit record. If the breach cannot be immediately isolated, the deployment MUST be suspended.
6.3 Trust Downgrade Rules
When data crosses from a lower-trust zone to a higher-trust zone, the data MUST be downgraded to the trust level of the originating zone and treated accordingly, regardless of its claimed origin. Trust downgrades are irreversible within a single enforcement transaction. No trust elevation may result from cross-boundary data passage.
A component MUST NOT treat data from TZ-2 as trusted because it was routed through TZ-3. A component MUST NOT treat data from TZ-8 as trusted because it was reformatted by TZ-3. Trust is assigned based on the original source zone, not the most recent forwarding zone. Any implementation that elevates trust based on forwarding path is INVALID.
Trust elevation through forwarding is a structural exploit path that allows untrusted data to be laundered into the enforcement trust domain through a trusted intermediary. Any enforcement decision influenced by laundered trust is INVALID. The affected interaction path MUST be remediated immediately.
6.4 Validation Requirements
Every cross-boundary interaction MUST be validated at the receiving boundary before the data or control signal is processed. Validation MUST confirm: structural integrity, cryptographic authenticity where applicable, zone-appropriate trust level, and conformance with the declared interaction protocol.
Partial validation is PROHIBITED. A cross-boundary interaction is either fully valid or fully invalid. There is no intermediate acceptance state. A validation failure on any single criterion MUST result in immediate rejection of the entire interaction.
No data or control signal crossing a trust zone boundary may be acted upon until it has been fully validated in conformance with this section. Partial validation is INVALID. A cross-boundary interaction validated on three of four criteria is NOT validated.
A validation failure MUST generate an audit record in TZ-9 identifying the rejection reason, the source zone, and the interaction type. The failed interaction MUST NOT be retried without resolving the validation failure. Repeated validation failures from the same source zone MUST be treated as a potential attack pattern and escalated to the governance authority.
#Untrusted Component Containment
Untrusted components MUST be contained. Containment means that a component cannot affect enforcement outcomes through any channel other than the formally defined, validated interaction interfaces specified in Section 6. Each class of untrusted component has specific containment requirements, failure scenarios, and escalation paths.
Model Providers (TZ-7)
- No network path may exist between TZ-7 components and TZ-4, TZ-5, TZ-6, or TZ-9 components.
- Inference requests MUST reach TZ-7 through TZ-3 only, and only when accompanied by a valid permit token.
- Outputs from TZ-7 MUST NOT be returned to any inside-boundary component.
- TZ-4 MUST NOT inspect or process model outputs. Enforcement authority ends with permit issuance.
- Direct routing bypass: TZ-3 routes to TZ-7 without a valid permit token. Enforcement bypass condition. Immediate suspension of TZ-3 integration required.
- Model output feedback loop: TZ-7 outputs are returned to TZ-4 or TZ-5. The inside-boundary component is contaminated by untrusted data. All decisions produced during contamination are INVALID.
- Permit token exfiltration: TZ-7 extracts and reuses permit token parameters. Full permit token rotation MUST be executed immediately. Audit review of all decisions issued under the compromised token series is required.
External APIs (TZ-8)
- TZ-8 components MUST have no connectivity to any inside-boundary component.
- Inside-boundary components MUST NOT introduce service dependencies on TZ-8 components.
- External dependencies required for operational purposes unrelated to enforcement MUST be isolated in a separately classified outside-boundary component.
- Supply chain compromise: An external dependency loaded by an inside-boundary component is compromised. The inside-boundary component is immediately reclassified as potentially compromised. All decisions produced after the compromise point require forensic review.
- Data exfiltration channel: A TZ-8 component receives inside-boundary data through an undocumented channel. Classified as a cross-zone leakage event (TV-04). Critical incident response required.
Plugins and Extensions
- No plugin, extension, or dynamically loaded module may be executed within the enforcement boundary without prior formal evaluation and explicit inclusion in the inside-boundary component inventory.
- Plugins executing within TZ-3 or TZ-7 are subject to the untrusted zone rules of those zones without exception.
- Plugins that interact with TZ-4 MUST present authenticated requestor identities and MUST pass all TZ-4 validation requirements.
- Unevaluated plugin execution inside boundary: Immediate suspension of all enforcement operations. Complete boundary audit required before resumption.
- Plugin identity spoofing: A plugin presents a fabricated authenticated identity to TZ-4. Constitutes a TV-01 boundary breach. Suspension and forensic review required.
User Inputs (TZ-1, TZ-2)
- All user inputs MUST be sanitized and structurally validated before submission to any inside-boundary component.
- TZ-4 MUST NOT execute any logic derived from or influenced by raw user input.
- Declared intent is used only as a lookup key in consent and policy evaluation. It is NEVER executed, interpreted, or evaluated as a general-purpose instruction.
- No user input may influence enforcement decision logic directly or through an intermediary.
- Intent field injection: A user crafts an intent declaration that causes TZ-4 to execute unintended logic paths. The affected decision is INVALID. Input validation MUST be hardened before enforcement resumes.
- Consent scope inflation: A user submits a consent declaration with a broader scope than intended through exploiting validation gaps in TZ-1. All downstream enforcement decisions relying on the inflated consent record are INVALID pending registry audit.
No inside-boundary component MUST initiate or participate in a direct interaction with TZ-7. All model interactions MUST occur outside the enforcement boundary, initiated by TZ-3 upon receipt of a valid permit token from TZ-4.
#Trust Violation Scenarios
The following trust violation scenarios are explicitly recognized by this specification. Each scenario defines a detection condition, a mandatory response, and a conformance consequence. Mandatory responses are unconditional. No operational condition, performance requirement, or availability constraint overrides a mandatory response. Reduction in response severity for any enumerated scenario constitutes an independent non-compliance condition.
| ID | Violation Type | Detection Condition | Mandatory Response | Conformance Consequence |
|---|---|---|---|---|
| TV-01 | Boundary Breach | An inference request reaches TZ-7 without a valid TZ-4-issued permit token, detectable through permit token verification at the model access point or through audit log correlation. | Immediate block of request. Session termination. Critical audit record generation. Governance authority notification. Immediate suspension of the originating integration account pending investigation. | All enforcement decisions produced by the affected integration from the point of boundary breach are INVALID. Certification is suspended. Resumption requires full architectural audit and re-certification. |
| TV-02 | Implicit Trust Introduction | An inside-boundary component is found accepting data, instructions, or configuration from a component absent from the authorized trust inventory, without explicit validation per Section 6.4. | Immediate quarantine of the affected component. Suspension of all enforcement operations routed through it. Full audit of all decisions produced during the implicit trust exposure period. Invalidation of affected decisions pending audit outcome. | The affected component is reclassified as untrusted. All decisions it participated in are INVALID pending audit. Deployment is NON-COMPLIANT until trust inventory is remediated and full re-certification is obtained. |
| TV-03 | Enforcement Bypass | Audit log analysis reveals a permitted inference operation not preceded by a logged enforcement decision for the same request identifier, or a permit token presented at model access does not match the TZ-4-issued token. | Immediate suspension of the relevant TZ-3 integration. Invalidation of all permit tokens currently in circulation for that integration. Full forensic review of the bypass mechanism. Governance authority report within the timeframe defined in the applicable governance configuration. | The deployment's enforcement guarantee is null for the period of bypass. All inference operations during the bypass period are unenforceable. QODIQA conformance certification is immediately revoked pending investigation outcome. |
| TV-04 | Cross-Zone Data Leakage | Inside-boundary data — including enforcement decision logic, policy content, consent records, or audit entries — is found in TZ-7 or TZ-8 through a channel not defined in the cross-boundary interaction model. | Critical security incident classification. Execution of the incident response procedure in the QODIQA Security and Cryptographic Profile. Revocation of all signing keys potentially exposed during the leakage period. Notification of affected consent subjects. Immediate certification suspension. | The confidentiality and integrity of the enforcement boundary are compromised. All enforcement decisions produced after the leakage start point require forensic review. Certification MUST NOT be reinstated without independent security audit. |
| TV-05 | Consent Registry Integrity Failure | TZ-4 receives a consent validity response from TZ-5 that fails signature verification, contains a timestamp outside the acceptable validity window, or references a consent record absent from the tamper-evident log. | Response treated as INVALID. Deny decision issued for the pending request. Audit record generated indicating registry integrity failure. TZ-5 suspended as trusted component. Fail-closed on all subsequent requests until TZ-5 trust is re-established through re-verification. | TZ-5 is downgraded to untrusted status. All enforcement decisions issued while TZ-5 integrity was compromised MUST be reviewed. Decisions relying on the compromised consent state are INVALID. |
| TV-06 | Policy Version Integrity Failure | TZ-6 returns a recommendation based on a policy version whose hash does not match the canonical hash in the enforcement governance record, or the policy version identifier is unrecognized by the governance authority. | Recommendation treated as INVALID. Deny decision issued for the pending request. Audit record generated indicating policy integrity failure. All policy evaluations halted until the verified policy version is loaded and confirmed. Review of all decisions issued under the unverified policy version. | TZ-6 is downgraded to untrusted status for the period of policy version integrity failure. Decisions based on the unverified policy are INVALID and MUST be disclosed to relying parties. |
In any trust violation scenario not enumerated in Table 8-A, the system MUST default to deny. Absence of a specific enumerated response rule for a detected anomaly mandates the most conservative available response: block the request, generate a critical audit record, and escalate to the governance authority. Permit issuance is PROHIBITED when the system state is anomalous.
#Trust Reduction Strategy
The QODIQA trust model MUST be continuously hardened. Trust reduction is a mandatory evolution direction, not an optional improvement. Each rule below is normative.
Rule 1 — Assumption Elimination
Every existing trust relationship MUST be reviewed at each formal version cycle to determine whether the underlying assumption remains valid. Where an assumption can be replaced by a cryptographic verification, the substitution is MANDATORY. Where an assumption cannot be eliminated, it MUST be documented as a known trust dependency and tracked as a risk item under the QODIQA Risk and Assumption Disclosure Annex.
Undocumented trust assumptions are NON-COMPLIANT. An assumption-to-verification substitution deferred without documented justification is NON-COMPLIANT. Each version cycle MUST produce a trust assumption delta report enumerating: assumptions eliminated, assumptions pending elimination, and assumptions accepted as residual with risk justification.
Trust assumptions that persist without review accumulate as undocumented risk. A deployment that fails to produce a trust assumption delta report at each version cycle is NON-COMPLIANT and MUST NOT have its certification renewed.
Rule 2 — Progressive Hardening
Each successive version of this specification MUST reduce, or hold constant, the total number of trust grants in the canonical trust model. Trust grants MUST NOT be added except where a new component is formally incorporated into the inside-boundary component set through the full governance process. Trust grants MUST NOT be added to address operational convenience, performance optimization, or integration simplification.
The trust grant count at version N+1 MUST be less than or equal to the trust grant count at version N. Any version in which the trust grant count increases without a formally approved boundary expansion is NON-COMPLIANT.
A version that expands the trust surface without formal approval introduces unreviewed trust dependencies into the architecture. The affected version MUST NOT be deployed in production. The governance authority MUST review and explicitly approve any trust surface expansion before it is permitted in a normative version.
The total trust grant count of the canonical trust model MUST NOT increase between successive specification versions without a formally approved, governed boundary expansion. A version violating this invariant MUST NOT be deployed.
Rule 3 — Reduction of Conditional Trust Dependencies
Implementations MUST actively reduce dependencies on conditionally trusted components. The conditional trust assigned to TZ-5 (Consent Registry) is the highest residual trust dependency in the architecture. Implementations MUST prioritize cryptographic mechanisms that enable TZ-4 to verify consent validity without relying on a live registry response, such as cryptographically self-contained consent tokens with short validity periods and embedded revocation indicators.
Implementations MUST document the maximum tolerated TZ-5 unavailability period before fail-closed behavior is triggered. This period MUST decrease at each version cycle where architectural changes permit. An implementation with no documented TZ-5 unavailability tolerance bound is NON-COMPLIANT.
Unreduced conditional trust dependencies sustain attack surfaces that cryptographic self-containment would eliminate. An implementation that retains avoidable conditional trust dependencies without documented justification is failing its trust reduction obligation. Certification renewal MUST NOT be granted without evidence of active trust reduction effort.
#System Invariants
The following invariants MUST hold continuously in every conformant QODIQA implementation. An invariant is a property that MUST be true at every observable point in system operation, including degraded and adversarial conditions. Invariants I-01 through I-08 are referenced at their point of first relevance throughout this specification and consolidated here for auditability. Failure of any invariant is a critical system fault requiring immediate fail-closed response.
Definitions 1, 2, and 3 in Section 1 are immutable at runtime. No operational condition modifies the scope of any definition. Redefinition without formal specification revision is NON-COMPLIANT. First referenced: Section 1.
No inference request may produce a model output unless a valid, gateway-issued permit token for that specific request exists and has been verified by the forwarding component. No exception. First referenced: Section 3 (TZ-4).
No component MUST treat another component as trusted unless the trust relationship has been explicitly established through a defined trust contract and the conditions of that contract have been verified for the current interaction.
No data or control signal crossing a trust zone boundary MUST be acted upon until it has been fully validated per Section 6.4. Partial validation is INVALID. First referenced: Section 6.4.
No inside-boundary component MUST initiate or participate in a direct interaction with TZ-7. All model interactions MUST originate from TZ-3 upon receipt of a valid permit token. First referenced: Section 7.
A permit token MUST NOT be issued unless both a signed TZ-5 consent validity affirmation and a TZ-6 policy permit recommendation have been received and verified for the specific request. Absence of either MUST result in deny. First referenced: Section 5.
Every enforcement decision — permit or deny — MUST generate a corresponding audit record in TZ-9 before the decision is communicated to the requesting component. A decision without a pre-committed audit record MUST NOT be issued. First referenced: Section 3 (TZ-9).
Trust granted to any component is scoped exclusively to that component and the capabilities in its trust contract. Trust MUST NOT propagate to any third component through any mechanism. First referenced: Section 4.5.
The composition of the inside-boundary component set MUST NOT change at runtime. Any change requires a governed specification revision and deployment re-certification. An undocumented runtime change is a critical security incident. First referenced: Section 2.4.
#Non-Compliance Conditions
Each condition below independently constitutes non-compliance with this specification. A NON-COMPLIANT implementation MUST NOT assert QODIQA conformance and MUST NOT be presented to relying parties as QODIQA-conformant. Non-compliance conditions are individually sufficient; satisfaction of all other requirements does not offset any single violation.
- Missing boundary definitions. The implementation does not maintain a documented inside-boundary component inventory, or the inventory does not cover all components participating in enforcement, consent resolution, policy evaluation, or audit record generation.
- Implicit trust. Any trust relationship exists in the implementation that is not documented in the trust inventory and backed by an explicit trust contract satisfying Section 4.2.
- Enforcement outside the gateway. Any enforcement decision is made, or any permit token is issued, by a component other than TZ-4.
- Undefined zones. Any component participating in enforcement-related operations is not assigned to one of the nine canonical trust zones defined in Section 3.
- Fail-open behavior. The system issues a permit decision when TZ-4 is unavailable, when consent verification fails, when policy evaluation fails, or when any pre-condition in Section 5 cannot be confirmed.
- Trust propagation. The implementation relies on transitive trust in any enforcement-relevant operation.
- Unlogged decisions. Any enforcement decision is issued without a corresponding audit record committed to TZ-9 before decision delivery.
- Boundary bypass. Any inference request reaches TZ-7 through a path that does not traverse TZ-4.
- Non-revocable trust. Any trust grant exists for which no revocation mechanism has been defined and successfully tested.
- Unverified policy evaluation. Any enforcement decision is based on a policy evaluation performed against a policy version not verified against the canonical policy hash.
- Undocumented trust assumptions. Any trust assumption exists in the implementation that is not documented in the trust assumption register maintained under the QODIQA Risk and Assumption Disclosure Annex.
- Invalid architecture patterns. The implementation matches any pattern enumerated in Section 5 under "Invalid Architectures."
#Conformance Requirements
QODIQA conformance with this specification requires demonstrable satisfaction of all requirements below. All items are mandatory. Partial conformance is not recognized. A claim of conformance that cannot be substantiated by evidence for every item below is INVALID.
What Must Be Proven
- The inside-boundary component inventory is complete, accurate, and maintained under the QODIQA Change Log and Version Control Protocol, demonstrable through version-controlled governance records.
- No inference request can reach TZ-7 without traversing TZ-4, demonstrable through architectural analysis and network topology documentation reviewed by an independent auditor.
- Every trust relationship in the implementation is documented in a trust inventory backed by explicit trust contracts satisfying Section 4.2, demonstrable through inspection of governance documentation.
- Fail-closed behavior per Sections 5 and 8 is implemented without exception, demonstrable through fault injection test results.
- All eight system invariants in Section 10 hold under normal, boundary-condition, and adversarial operation, demonstrable through structured test evidence.
What Must Be Testable
- Blocking behavior of TZ-4 for requests failing pre-condition validation, tested using the QODIQA Conformance Test Suite test cases.
- All six trust violation responses in Table 8-A, tested through controlled scenario injection with documented outcomes.
- Non-bypassability of the enforcement boundary, tested through network-level bypass attempts as defined in the Conformance Test Suite.
- Revocability of every trust grant in the trust inventory, tested through revocation execution and subsequent interaction attempt.
- Cryptographic verification of all cross-boundary signals from TZ-5 and TZ-6, tested through signature forgery rejection scenarios.
- Containment failure escalation paths defined in Section 7, tested through controlled containment breach scenarios.
What Must Be Auditable
- Every enforcement decision MUST be reconstructible from the TZ-9 audit record without access to runtime state.
- The policy version applied to every enforcement decision MUST be identifiable from the audit record.
- The consent state consulted for every enforcement decision MUST be identifiable from the audit record and verifiable against the consent registry log.
- The complete trust inventory MUST be available for inspection by authorized auditors at any time.
- The trust assumption delta report MUST be available for every completed version cycle.
- Any change to the inside-boundary component inventory MUST be recorded in the change log with the authorizing governance event referenced.
#Final Deterministic Statement
This specification defines the complete, closed system boundary and trust model for deterministic runtime consent enforcement architecture. No element of the boundary or trust model is open to interpretation. No gap in this specification may be filled by implementer discretion. Where this specification is silent on a specific scenario, the fail-closed rule applies unconditionally.
Any violation of the system boundary as defined in Section 2 immediately and completely invalidates all QODIQA conformance claims for the affected deployment. A deployment with a violated boundary MUST NOT assert that consent has been enforced for any inference operation, regardless of the intended behavior of TZ-4.
Any violation of the trust model — including implicit trust introduction, trust propagation across components, or operation of a trust grant without a defined revocation mechanism — immediately invalidates the integrity of all enforcement decisions produced under the affected trust configuration. Decisions produced under a violated trust model MUST be disclosed to relying parties as potentially invalid.
Failure of any system invariant in Section 10 is a critical architectural fault. The affected deployment MUST be suspended immediately. Enforcement decisions produced during the period of invariant failure MUST NOT be presented as valid enforcement evidence. Resumption of deployment MUST be preceded by root cause analysis, remediation, and re-certification.
Compliance with this specification requires full, continuous, and demonstrable adherence to every boundary definition, trust zone definition, trust model principle, enforcement boundary constraint, cross-boundary interaction rule, containment requirement, violation response, and invariant defined herein. No partial compliance is recognized. No waiver is permitted without formal specification revision under the QODIQA Governance Charter. The QODIQA system boundary and trust model is not a design recommendation. It is a structural requirement. Implementations that satisfy it can assert deterministic enforcement. Implementations that do not satisfy it cannot.
#Document Status and Corpus Alignment
This document is a foundational specification within the QODIQA corpus. It defines the complete system boundary and trust model governing the QODIQA deterministic runtime consent enforcement architecture. All boundary definitions, trust zone assignments, enforcement location constraints, cross-boundary interaction rules, and system invariants set forth herein are normative and binding on all conformant implementations.
This specification is a prerequisite for the correct interpretation of all other QODIQA corpus documents that reference trust zones, enforcement boundaries, or cross-boundary interaction rules. Implementations MUST satisfy the requirements of this document before asserting conformance with any other QODIQA specification.
This document MUST be read together with the following related specifications:
- QODIQA — Consent as Infrastructure for Artificial Intelligence Technical Whitepaper
- QODIQA — Core Standard for Deterministic Runtime Consent Enforcement
- QODIQA — 68-Point Enforcement Framework for Deterministic Runtime Consent Enforcement
- QODIQA — Threat Model and Abuse Case Specification
- QODIQA — Reference Architecture for Deterministic Runtime Consent Enforcement
- QODIQA — Security and Cryptographic Profile for Runtime Consent Enforcement
- QODIQA — Conformance Test Suite Specification for Deterministic Runtime Consent Enforcement
- QODIQA — Certification Framework for Deterministic Runtime Consent Enforcement
- QODIQA — Governance Charter for the QODIQA Standard Corpus
- QODIQA — Terminology and Normative Definitions
- QODIQA — Residual Risk and Assumption Disclosure Annex
Version 1.0 represents the initial formal release of this document as part of the QODIQA standard corpus.
For strategic inquiries, architectural discussions, or partnership exploration:
Bogdan Duțescu
0040.724.218.572