QODIQA Terminology and
Normative Definitions

A system property whereby every AI execution request is evaluated against explicitly declared consent state and applicable policy rules at the moment of invocation, producing a bounded output — allow, deny, or allow with stated restrictions — that is reproducible given identical inputs. The evaluation process introduces no probabilistic inference, no contextual assumption, and no default-to-permit behavior.

A system in which, given a fixed set of inputs and a fixed rule set at a fixed version, the evaluation process always yields the same output with no variance. Determinism within the QODIQA framework applies specifically to the enforcement evaluation path and does not constrain the behavior of AI models or downstream services operating outside that path.

The temporal and computational interval during which an AI execution request is processed, from the point of request submission to the point at which an authorized or denied execution outcome is produced. All consent evaluation and enforcement operations within the QODIQA framework occur within this interval.

An explicit, machine-readable authorization record granted by an identified principal, scoped to a defined action type, bounded by a declared purpose, constrained by temporal validity limits, and subject to revocation. Consent within the QODIQA framework is not inferred, assumed, or derived from behavioral signals. It exists as a discrete, addressable record in the Consent Registry.

A cryptographically signed, immutable record representing a discrete consent state at a specific point in time. A Consent Artifact contains, at minimum: the identity of the consenting principal, the scope of the consented action, the declared purpose, the temporal validity window, and an integrity anchor. Consent Artifacts are the unit of consent evaluated by the Policy Engine.

The authoritative, append-only data store in which all Consent Artifacts are recorded, indexed, and made retrievable for enforcement evaluation. The Consent Registry is the sole source of consent truth within the QODIQA framework. Consent not recorded in the Consent Registry does not exist for enforcement purposes.

The system component through which all AI execution requests must pass before reaching the execution layer. The Enforcement Gateway is responsible for receiving execution requests, triggering consent validation, invoking policy evaluation, and returning a deterministic enforcement decision. No execution request may bypass the Enforcement Gateway.

The complete set of conditions, constraints, and input parameters that fully determine the output of a single enforcement evaluation. A Decision Boundary is closed: no inputs outside its declared scope affect the evaluation outcome. Extension of the Decision Boundary requires a versioned policy amendment.

The component responsible for evaluating declared execution intent against applicable policy rules and resolved consent state, producing a deterministic enforcement decision. The Policy Engine operates on explicitly declared inputs only. It does not access raw data, perform semantic interpretation of content, or apply probabilistic risk scoring.

A condition arising during enforcement evaluation that causes the Policy Engine to halt processing and return a deny decision. Blocking Events include, without limitation: absent consent, expired consent, consent scope mismatch, policy rule violation, and integrity verification failure. All Blocking Events are recorded as Audit Artifacts.

The system condition in which, when required inputs for enforcement evaluation are absent, incomplete, or unresolvable, the default output is a deny decision. No execution proceeds in the absence of a complete and valid enforcement evaluation. Fail-Closed State is a mandatory property of all QODIQA-conformant enforcement implementations.

The state in which an AI execution request has been received by the Enforcement Gateway but has not been authorized. A system in Non-Execution State has neither permitted nor committed to any downstream action. The Non-Execution State is the initial and default state for all requests entering the Enforcement Gateway.

A deterministic, time-stamped enforcement decision produced by the Policy Engine that permits a specified execution request to proceed under stated conditions. Execution Authorization is not granted by default and is not presumed by the absence of a deny decision. It must be explicitly produced as an output of a completed enforcement evaluation.

The declared limit of the scope of execution authorized for a given AI invocation. The Inference Boundary constrains what the AI system may produce, access, or affect as a result of an authorized execution. Outputs or effects falling outside the declared Inference Boundary constitute a boundary violation and SHALL be treated as a Blocking Event in subsequent evaluations.

The process by which the enforcement system verifies that a Consent Artifact exists in the Consent Registry, is cryptographically intact, is temporally valid at the moment of evaluation, and is scoped to cover the action declared in the execution request. Consent Validation precedes Policy Evaluation in all enforcement flows.

An operation performed by the Enforcement Gateway as a result of a completed enforcement evaluation. Enforcement Actions include: granting Execution Authorization, returning a deny decision, returning a conditional authorization with stated restrictions, and recording an Audit Artifact. An Enforcement Action is distinct from and independent of any downstream AI operation.

A tamper-evident, cryptographically anchored record generated at the completion of every enforcement evaluation, capturing the complete set of inputs, the resolved consent state, the applicable policy version, and the resulting Enforcement Action. Audit Artifacts are appended to the Immutable Log and are the primary mechanism through which enforcement decisions are made verifiable and reproducible.

A data record whose content, once written, cannot be altered, deleted, or overridden by any system operation or administrative action. Within the QODIQA framework, Immutable Records include Consent Artifacts, Audit Artifacts, and policy version snapshots. Immutability is enforced through append-only storage architecture and cryptographic integrity anchoring.

A cryptographic value — specifically a digital signature or a hash chain element — bound to a specific record and used to verify that the record's content has not been altered since its creation. Cryptographic Integrity Anchors are required for all Consent Artifacts and Audit Artifacts within QODIQA-conformant implementations.

The logical tier of the QODIQA reference architecture comprising the Enforcement Gateway, Policy Engine, and Consent Validation components. The Enforcement Layer is the sole site of enforcement decision-making. No other architectural layer produces or modifies enforcement decisions.

The defined programmatic interface through which the Enforcement Layer queries the Consent Registry. The Registry Interface is the exclusive access path to Consent Artifact data for enforcement evaluation purposes. Direct registry access by components outside the Enforcement Layer is PROHIBITED.

The bounded component within the Policy Engine responsible for applying a specific versioned policy rule set against resolved consent state and declared execution intent. The Policy Evaluation Module receives only the inputs required for evaluation and returns only a binary or ternary enforcement decision. It retains no state between evaluations.

The system or procedural layer responsible for verifying that an implementation satisfies the requirements of the QODIQA Conformance Test Suite and Certification Framework. The Conformance Validation Layer operates independently of the Enforcement Layer and does not participate in runtime enforcement decisions.

A defined tier of conformance achievement, as specified in the QODIQA Certification Framework, indicating the scope of control points satisfied by an implementation. Certification Levels are ordinal, cumulative, and verifiable. Attainment of a higher Certification Level requires satisfaction of all requirements at lower levels plus additional level-specific requirements.

The complete sequence of processing steps — from request receipt at the Enforcement Gateway through consent validation, policy evaluation, and Audit Artifact generation — that produces an enforcement decision. The Deterministic Evaluation Path is fully defined, has no optional branches under normal operating conditions, and must be traversed in its entirety for each request.

The complete set of defined control points at which enforcement decisions are made or enforcement conditions are checked within a QODIQA implementation. The Control Surface is enumerated in the QODIQA — 68-Point Enforcement Framework for Deterministic Runtime Consent Enforcement — Version 1.0 and constitutes the measurable scope of enforcement coverage.

A declared demarcation between system components or operational domains across which data, requests, or credentials must be explicitly validated before being accepted as input to enforcement evaluation. Trust is not transitive across Trust Boundaries. Each boundary crossing requires independent verification.

Any system, service, or data source not contained within the QODIQA Enforcement Layer upon which the enforcement evaluation process relies. External Dependencies are subject to availability failure and MUST be treated as potential sources of Blocking Events. A QODIQA-conformant implementation documents all External Dependencies and specifies failure behavior for each.

A single, discrete request submitted to the Enforcement Gateway for evaluation, associated with one declared intent, one identified principal, and one target action scope. Each Runtime Invocation is evaluated independently. The outcome of a prior Runtime Invocation does not affect the evaluation of a subsequent one, except where applicable policy rules explicitly reference prior enforcement history.

The association between a record — such as a Consent Artifact or Audit Artifact — and a cryptographic value such that any modification to the record's content renders the cryptographic value invalid. Cryptographic Binding is achieved through digital signature or keyed hash mechanisms as specified in the QODIQA — Security and Cryptographic Profile for Runtime Consent Enforcement — Version 1.0.

The process of confirming that a record's content matches its Cryptographic Binding, establishing that the record has not been altered since its creation. Integrity Verification is a mandatory step in Consent Validation and MUST be performed for every Consent Artifact retrieved from the Consent Registry during an enforcement evaluation.

The capability of a system component to identify that a record's content does not match its Cryptographic Binding. Detection of tamper constitutes an Integrity Failure Condition and SHALL trigger a Blocking Event. Tamper Detection is distinct from tamper prevention; it is a detection and response property, not a prevention property.

The cryptographic operation by which a Cryptographic Integrity Anchor is computed and attached to a record at the time of its creation. Artifact Signing uses private key operations as specified in the QODIQA — Security and Cryptographic Profile for Runtime Consent Enforcement — Version 1.0 and is performed exactly once per record, at creation time. Re-signing of existing records is PROHIBITED.

The defined operational and architectural perimeter within which cryptographic key material used for Artifact Signing is generated, stored, and used. Key material SHALL NOT cross the Key Management Boundary in plaintext form. Access to key material is restricted to the signing operation and is not available to enforcement evaluation logic.

The append-only, cryptographically chained sequence of Audit Artifacts produced by the Enforcement Layer. Entries in the Immutable Log cannot be altered or deleted after being written. The Immutable Log is the primary evidence source for enforcement audits and reproducibility verification.

A record for which the only permitted write operation is creation. No update, deletion, or modification operation is permitted after creation. All Consent Artifacts and Audit Artifacts within the QODIQA framework are Append-Only Records. Revocation of a Consent Artifact is achieved through the creation of a new Revocation State record, not through modification of the original.

A record in the Consent Registry asserting that a specific Consent Artifact is no longer valid as of a declared timestamp. A Revocation State record does not alter the original Consent Artifact. Consent Validation MUST check for the existence of a Revocation State record for any Consent Artifact retrieved during an enforcement evaluation. A revoked Consent Artifact SHALL NOT authorize execution.

A system state in which the result of Integrity Verification for a record is negative — indicating that the record's content does not match its Cryptographic Binding. An Integrity Failure Condition is an immediate Blocking Event. The affected record SHALL NOT be used as input to enforcement evaluation. The condition SHALL be recorded in the Immutable Log.

The verifiable state of an implementation in which all mandatory requirements of the applicable QODIQA specification set — as assessed through the Conformance Test Suite — are satisfied. Conformance is a technical determination. It does not imply, guarantee, or substitute for regulatory compliance with any external legal framework.

The formal recognition issued by an authorized certifying body upon verified attainment of a specified Certification Level. Certification is based on documented evidence of Conformance and does not extend beyond the scope, version, and configuration of the implementation assessed. Certification SHALL NOT be claimed for configurations, versions, or deployment contexts not covered by the assessment.

The state of an organization or system in which applicable legal, regulatory, or contractual obligations are satisfied. Compliance is a legal determination, not a technical one. QODIQA Conformance and Certification are evidence inputs that MAY be relevant to a compliance determination but do not constitute compliance with any regulatory framework. Organizations remain solely responsible for their own compliance assessments.

A formal statement accompanying a conformance or certification claim identifying the specific control points, domains, or requirements that fall outside the scope of the assessed implementation. Non-Coverage Disclosures are mandatory for partial-scope implementations. Their absence is treated as a claim of full-scope coverage.

A declared boundary on the applicability of a QODIQA specification, certification claim, or conformance assessment. Scope Limitations identify the deployment contexts, data categories, jurisdictions, or operational conditions to which an assessed claim applies. Claims made outside a declared Scope Limitation are unverified.

A versioned modification to a QODIQA specification document, processed through the change control procedure defined in Section 8. An Amendment that alters a normative definition in this specification constitutes a new version of this document. Amendments are recorded as Immutable Records and are appended to the document revision history.

The current, authoritatively published version of a QODIQA specification document as recognized by the QODIQA Governance Charter. The Canonical Version is the only version against which conformance assessments and certification claims are valid. Prior versions are superseded upon publication of a Canonical Version but remain accessible as archived references.

A modification to a QODIQA specification that alters the meaning, scope, or binding status of a normative requirement such that implementations previously assessed as conformant may no longer satisfy the amended requirement without modification. Breaking Changes require a major version increment and mandatory re-assessment of affected certified implementations.

Any Amendment to a QODIQA specification document that alters, adds, or removes normative requirements. Normative Revisions are distinguished from editorial revisions, which correct typographical or formatting errors without changing meaning. Normative Revisions require a version increment according to the versioning scheme defined in Section 8.

The condition in which the practical application of a term diverges from its definition in this specification, whether through informal restatement, paraphrase, omission, or contextual substitution. Interpretive Drift constitutes semantic non-conformance. Its detection obligates the responsible party to align usage with this specification through documented correction.