QODIQA Certification Framework
for Deterministic Runtime Consent Enforcement

#Executive Certification Overview

The QODIQA Core Standard defines the normative requirements for deterministic runtime consent enforcement. The Implementation Playbook defines how those requirements are realized in infrastructure. The 68-Point Enforcement Framework defines the enumerated control set against which deployments are assessed. This Certification Framework defines how conformance to those requirements is measured, evidenced, and formally affirmed.

These four documents form the complete QODIQA corpus. Each is normatively subordinate to the Core Standard. This Framework is operationally subordinate to the Implementation Playbook for infrastructure guidance, but it is the authoritative specification for all conformance assessment procedures. No certification activity that deviates from the procedures defined here produces a valid QODIQA certification outcome.

1.1 Purpose of Certification

Certification under this Framework serves a single purpose: to produce a verifiable, time-bounded attestation that a specified deployment of QODIQA enforcement infrastructure satisfies the normative requirements of the QODIQA corpus at a declared assurance level. That attestation must be reproducible, evidence-backed, and falsifiable. An attestation that cannot be independently re-derived from the archived evidence is not a valid certification under this Framework.

1.2 Relationship to the Core Standard

The Core Standard defines what a conformant system must do. This Framework defines how conformance to those requirements is demonstrated. The Core Standard is normative over enforcement semantics; this Framework is normative over certification procedure. In the event of conflict between this Framework's procedural requirements and the Core Standard's enforcement requirements, the Core Standard prevails for enforcement semantics. This Framework prevails for all matters of evidence, testing, and attestation procedure.

1.3 Relationship to the Implementation Playbook

The Implementation Playbook specifies how conformant infrastructure is built and operated. This Framework specifies how the resulting infrastructure is assessed. The Playbook's conformance checklist (Sections 10.1 through 10.6) defines the baseline evidentiary requirements. This Framework extends those requirements with structured test procedures, evidence packaging specifications, assessor qualification criteria, and certification lifecycle management. The Playbook and this Framework are complementary instruments within the same corpus; the Playbook is the build specification, and this Framework is the audit specification.

1.4 Institutional Scope

This Framework applies to any entity deploying QODIQA enforcement infrastructure for production use and seeking to make a formal conformance claim. The Framework is equally applicable to self-attestation by the deploying organization, third-party attestation by an independent auditor, or certification by an accredited certification body. The procedures defined here are identical regardless of the attestation pathway; only the authority and independence requirements differ.

#Conformance Definition Model

Conformance to the QODIQA corpus is not a binary attribute. It is a structured claim composed of four distinct conformance dimensions, each of which must be independently satisfied for a certification claim to be valid at any level. A deployment that satisfies three of four dimensions is not partially conformant—it is non-conformant for the dimensions it fails, and the overall certification claim must reflect that deficiency.

2.1 Conformance Dimensions

2.2 Declared, Verified, and Certified Conformance

Three conformance claim types are recognized under this Framework. They differ in the independence and depth of the assessment process that supports them. They are not interchangeable; no claim type may be represented as another.

2.3 Conformance Boundary

A conformance claim is always bounded to a specific deployment, a specific certification level, a specific policy version, and a specific assessment date. The claim does not extend to other deployments of the same software, future policy versions, or deployments at higher maturity levels that have not been independently assessed. The conformance boundary must be explicitly declared in any public conformance statement.

A change in any of the following constitutes a boundary-breaking event that requires re-assessment: deployment topology modification; component replacement or major version upgrade; policy version change; change to revocation TTL commitment; change to the audit ledger infrastructure; or a security event affecting the key hierarchy.

#Certification Levels

Four certification levels are defined. Each level is a complete, independently assessable conformance designation. Higher levels are not additive tiers — each level is a fully specified set of requirements that must be satisfied independently. A deployment seeking Level 3 certification must satisfy all Level 3 requirements; it is not sufficient to satisfy Level 1 and Level 2 requirements and claim Level 3 designation. The assessor must evaluate the deployment against the specific, complete requirements of the claimed level.

#Certification Evidence Requirements

Evidence artifacts are the material basis of all conformance claims. An evidence artifact is a structured, time-stamped, tamper-evident record produced by a specific test execution, measurement collection, configuration inspection, or system event. Evidence artifacts are not narratives or self-descriptions—they are machine-verifiable records that a qualified assessor can independently examine and cross-reference against the requirements they attest to.

4.1 Evidence Artifact Taxonomy

4.2 Evidence Package Specification

Evidence for a certification assessment must be assembled into a structured evidence package. The evidence package is the complete, self-contained artifact set submitted to the assessor. It must include: a manifest listing all artifact files with their SHA-256 hashes; a conformance claim statement identifying the certification level, deployment boundary, and policy versions assessed; copies of all required evidence artifacts with timestamps and provenance; AL export for the assessment period covering all normative record types; and a signed declaration from the infrastructure lead attesting to the completeness and authenticity of the package contents.

The assessor must not accept an evidence package that is missing any required artifact type for the claimed certification level, that contains artifacts whose timestamps fall outside the assessed deployment period, or whose AL export hash chain fails verification. An incomplete or unverifiable evidence package is treated as evidentiary non-conformance, equivalent to a test failure for the controls whose evidence is missing.

4.3 Minimum Evidence Set by Level

#Conformance Test Methodology

Conformance testing under this Framework is structured testing against defined pass/fail criteria. Tests are deterministic in structure: given a specified test precondition, a specified stimulus, and a specified expected outcome, the test either passes or fails. There are no partial passes. A test result of "mostly compliant" or "substantially conformant" is not recognized; each test either produces the required outcome or it does not.

All conformance tests must be executed in an environment that is representative of the production deployment being assessed. Tests executed in a development or staging environment that differs from production in topology, component versions, or configuration do not produce valid evidence for a production deployment assessment.

5.1 Test Vector Validation

Test vector validation is the process of verifying that the enforcement function produces the expected decision for each member of a defined test corpus. The test corpus must be constructed before test execution and must be immutable during execution. The corpus hash must be computed and archived before the first evaluation pass. Any modification to the corpus after its hash is archived invalidates the test.

// Corpus composition requirements — minimum 500 vectors at CL-01
// Minimum 1000 vectors at CL-02 through CL-04

Mandatory vector categories:
  ACTIVE_token_full_scope_match        — expected: PERMIT  (≥ 10%)
  ACTIVE_token_scope_mismatch          — expected: DENY    (≥ 10%)
  REVOKED_token                        — expected: DENY    (≥ 10%)
  EXPIRED_token                        — expected: DENY    (≥ 10%)
  NOT_FOUND_token                      — expected: DENY    (≥ 5%)
  UNKNOWN_issuer                       — expected: DENY    (≥ 5%)
  boundary_context_hash_valid          — expected: PERMIT  (≥ 5%)
  boundary_context_hash_invalid        — expected: DENY    (≥ 5%)
  default_deny_no_matching_rule        — expected: DENY    (≥ 5%)
  policy_version_not_found             — expected: DENY    (≥ 5%)
  combined_multi_condition_permit      — expected: PERMIT  (≥ 5%)
  combined_multi_condition_deny        — expected: DENY    (≥ 5%)
  // Remaining vectors: operator-defined for deployment-specific policy coverage

Corpus serialization:
  corpus_hash = SHA-256(canonical_serialize(all_vectors_sorted_by_id))
  corpus_hash archived before first evaluation pass
  corpus stored with evidence package; verifiable by assessor

5.2 Negative Test Cases

Negative test cases verify that the enforcement system does not permit what it must not permit. They are as important as positive test cases—a system that permits correctly but fails to deny correctly is non-conformant. The following negative test categories are mandatory at all certification levels:

• Revoked token must be denied; ACTIVE state returned by a non-linearizable read does not relax this requirement
• Request with no consent_id field must be denied at the EG extraction stage before CR query
• Request with invalid context_hash format (not matching sha256: prefix and format) must be denied
• Request referencing an unknown policy version must be denied by PE without evaluation
• Request from a caller with an expired mTLS certificate must be denied at transport layer before enforcement evaluation
• Request submitted after rate limit exceedance must be denied with RATE_LIMIT_EXCEEDED and produce AL record
• Request where AL write fails must never result in inference execution, regardless of PE decision
• Inference execution with missing, malformed, or HMAC-invalid artifact must be refused by inference system

5.3 Fail-Closed Validation Procedure

5.4 Revocation Race Condition Test

The revocation race condition test verifies that the system handles concurrent enforcement and revocation correctly and that the audit record correctly reflects both events. This test must be executed under load conditions representative of the production deployment, not under idle conditions.

procedure REVOCATION_RACE_TEST(consent_id C, load_rps R):

  Step 1: Establish baseline
    Confirm C.state = ACTIVE; run 100 requests for C at R req/s
    Verify all 100 produce PERMIT with AL records

  Step 2: Concurrent revocation
    At T0: begin continuous requests for C at R req/s
    At T0 + 50ms: commit revocation of C via RS
    Continue requests for C until T0 + TTL + 100ms

  Step 3: Collect results
    Extract all AL records for C between [T0, T0 + TTL + 100ms]
    Classify records as: PERMIT_BEFORE_REVOCATION or DENY_AFTER_REVOCATION

  Step 4: Verify invariants
    (a) All PERMIT records must have committed_at < revocation_committed_at + epsilon
        where epsilon = revocation propagation tolerance (max: TTL)
    (b) All DENY records after T0 + TTL must have reason = TOKEN_REVOKED
    (c) No PERMIT record exists at committed_at > T0 + TTL
    (d) Revocation propagation: qodiqa_revocation_propagation_ms P99 ≤ TTL
    (e) Conservative mode: if any EG did not acknowledge revocation at TTL/2,
        verify that EG applied DENY for affected consent_ids

  Pass criterion: all four invariants satisfied; no PERMIT after T0 + TTL

5.5 Policy Drift Detection Test

Policy drift occurs when a deployed PE instance diverges from the canonical frozen policy snapshot—either through unauthorized modification, version mismatch across PE instances, or snapshot corruption. The policy drift detection test verifies that all PE instances report identical policy versions and snapshot hashes, and that the integrity heartbeat detects any divergence.

• Query policy version and snapshot hash from all active PE instances; confirm they are identical. Any divergence is an immediate test failure.
• Verify the snapshot hash reported by each PE instance matches the SHA-256 hash in the corresponding AL POLICY_FROZEN record
• Inject a single-bit modification to a PE instance's local policy snapshot; verify PE detects the tamper at next integrity check and emits POLICY_LOAD_FAILURE
• Deploy a test PE instance with a syntactically valid but semantically different policy snapshot; verify it is rejected and does not join the enforcement pool
• Verify the integrity heartbeat detects PE policy version divergence within its scheduled interval

5.6 Artifact Recomputation Test

Artifact recomputation testing verifies that the Artifact Emitter produces bit-identical output for identical inputs under the same key and nonce. This is distinct from the determinism test: the determinism test verifies that the enforcement decision is reproducible; the artifact recomputation test verifies that the artifact encoding of that decision is reproducible. Both must hold for certification at CL-02 and above. A system that makes correct enforcement decisions but produces non-deterministic artifacts violates the integrity model because the inference system cannot reliably verify the artifact against a known expected value.

procedure ARTIFACT_RECOMPUTATION_TEST(sample_size N ≥ 100):

  Preconditions:
    AE is operational; PE is operational; current key K is active
    No key rotation in progress during test execution

  Step 1: Generate N input tuples
    ∀ i ∈ [1..N]:
      T_i = (consent_id_i, context_hash_i, policy_version, decision_i, nonce_i)
      A_i_first = AE.emit(T_i, K)
      Record A_i_first with timestamp ts_first_i

  Step 2: AE restart
    Perform controlled AE process restart
    Verify remote attestation re-executed (CL-04: mandatory; CL-02/03: log-only)
    Verify AE reports same key K loaded and verified

  Step 3: Recompute artifacts
    ∀ i ∈ [1..N]:
      A_i_second = AE.emit(T_i, K)   // same input tuple, same key, same nonce
      Record A_i_second with timestamp ts_second_i

  Step 4: Bit-identity verification
    ∀ i ∈ [1..N]:
      if A_i_first ≠ A_i_second: FAIL — non-deterministic artifact emission
        record: index=i, first_hash=SHA256(A_i_first), second_hash=SHA256(A_i_second)
        test terminates; all N results must pass

  Step 5: Inference system verification
    Submit A_i_first to inference system for 20 sampled inputs; verify acceptance
    Submit A_i_second to inference system for same 20 inputs; verify acceptance
    Verify inference system acceptance outcome is identical for both versions

  Pass criterion: ∀ i: A_i_first = A_i_second (byte-exact);
    inference system accepts both versions identically
  Evidence: test log with input tuple hashes, artifact hashes, restart timestamp;
    archived to AL as ARTIFACT_RECOMPUTATION_TEST record type

The artifact recomputation invariant must hold across all three failure modes: (a) AE process restart with key reload from persisted key store; (b) AE instance replacement within a multi-instance AE pool; and (c) AE recovery from a DENY state following a transient key verification failure. In all three cases, the recomputed artifact for a previously seen input must be bit-identical to the original artifact produced under the same key and nonce. An AE implementation that uses any timestamp, randomness source, or instance-specific state in the artifact encoding is structurally non-conformant at CL-02 and above.

#Determinism Verification Protocol

Determinism is the fundamental assurance property of QODIQA enforcement. It means that the enforcement function is a pure mathematical function of its inputs: given identical token state, context hash, and policy version, the function must return an identical decision on every invocation, on every PE instance, after every restart, and across every deployment that holds the same frozen policy snapshot. Determinism verification is a certification requirement at all levels and cannot be waived or approximated.

6.1 Frozen Context Extraction Method

A frozen context is the canonicalized, version-tagged representation of a processing request's enforcement-relevant attributes at the moment of evaluation. Frozen context extraction must produce a context object that is both complete and irreducible: complete in that all attributes that could affect the enforcement decision are present; irreducible in that no attribute is included that does not affect the enforcement decision. The frozen context extraction procedure must be identical to the canonical serialization procedure defined in the Implementation Playbook §8.1.

// FC-EXT-INV-01: Completeness
frozen_context(request R) must include:
  { consent_id, context_hash, policy_version,
    token.state, token.issuer, token.scope,
    token.issued_at, token.expires_at,
    request_nonce, caller_id }

// FC-EXT-INV-02: Canonical hash reproduction
canonical_hash(frozen_context) must be deterministic:
  ∀ C₁, C₂: semantically_equal(C₁, C₂) → canonical_hash(C₁) = canonical_hash(C₂)
  ∀ C: canonical_hash(C) is invariant under field reordering, whitespace, encoding

// FC-EXT-INV-03: Policy binding
frozen_context.policy_version must reference a FROZEN policy version
  PE must reject evaluation requests for non-FROZEN versions
  Frozen context produced for a non-FROZEN policy version is invalid for certification

// FC-EXT-INV-04: Timestamp exclusion
evaluation_timestamp must NOT be included in the canonical context hash
  The hash must be invariant across time for identical token states
  Token expiry is evaluated against the EG clock, not baked into the hash

// FC-EXT-INV-05: Scope normalization
token.scope must be canonical-sorted before hashing
  scope = sort_lexicographic(split(raw_scope, delimiter))
  Scope presentation order must not affect evaluation outcome

6.2 Hash Reproduction Test

The hash reproduction test verifies that the canonical serialization procedure produces identical hashes for semantically equivalent contexts. This test is a prerequisite for all higher-order determinism tests—if the canonicalization procedure is not reproducible, the determinism test results are not interpretable.

procedure HASH_REPRODUCTION_TEST(sample_size M ≥ 50):

  Step 1: Generate M base context objects with known canonical hashes
  Step 2: For each base context C_i, generate variants:
    V_i_1: field reordering (same fields, different JSON key order)
    V_i_2: whitespace injection (spaces after colons and commas)
    V_i_3: scope reordering (same scope values, different sequence)
    V_i_4: encoding variation (ASCII-escaped vs UTF-8 for non-ASCII values)

  Step 3: For each variant V_i_k:
    h_variant = canonical_hash(V_i_k)
    if h_variant ≠ canonical_hash(C_i): FAIL — non-deterministic canonicalization
      record: variant type V_i_k, divergent hash pair, test failure

  Step 4: Verify floating-point rejection
    Inject a context with a floating-point numeric field
    Verify: rejected with CONTEXT_TYPE_VIOLATION before hash computation

  Pass criterion: all M×4 variants produce hash identical to base context hash
  Evidence: hash reproduction test log with all input/output pairs archived

6.3 Policy Version Binding Verification

Policy version binding verification confirms that the enforcement function is bound to the declared policy version at the time of evaluation and that the binding is enforced at the PE layer—not inferred, approximated, or subject to runtime policy loading. The verifier must confirm that PE holds the exact policy snapshot whose SHA-256 hash matches the POLICY_FROZEN AL record for the declared policy version.

• Query PE for the current loaded policy version and snapshot hash; verify match against AL POLICY_FROZEN record for that version
• Submit an evaluation request referencing an unrecognized policy version; verify DENY with reason POLICY_VERSION_NOT_FOUND before any rule evaluation
• Submit a request referencing a valid but deprecated policy version (not the current active version); verify whether the deployment correctly handles version plurality or restricts to a single active version, per operator declaration
• Verify that the PE snapshot hash is computed at startup and verified before accepting any evaluation request; a PE that begins accepting requests before snapshot verification is non-conformant

6.4 Replay Invariant Validation

Replay invariant validation verifies that submitting the same enforcement request a second time produces the same enforcement outcome, given identical token state and policy version, but is correctly blocked if the request nonce has been previously consumed. These two properties are distinct and must be tested separately.

#Audit and Ledger Integrity Validation

The Audit Ledger (AL) is the evidentiary foundation of QODIQA enforcement accountability. Its integrity is not a performance characteristic—it is a precondition for any conformance claim. A certification assessment that cannot verify AL chain integrity is incomplete regardless of the results of all other tests. AL integrity validation is mandatory at every certification level.

7.1 Hash-Chain Validation Process

7.2 Log Tamper Detection

Tamper detection for the AL relies on the combination of the hash chain and the signed export mechanism. A tamper that modifies, deletes, or reorders records within a partition will produce a chain break at the tamper location. A tamper that appends fabricated records at the end of the chain cannot be detected by the chain alone—it requires cross-referencing the export against a prior integrity checkpoint or against an independently maintained record count.

At CL-03 and CL-04, the per-write chain integrity verification provides near-real-time tamper detection. Any write that does not produce a valid chain extension must trigger an immediate Class 0 alert. At CL-01 and CL-02, weekly and daily chain verification schedules allow for a longer tamper detection window, which must be disclosed in the conformance claim as part of the stated assurance boundary.

7.3 Retention Compliance Verification

Audit record retention requirements are defined by the operator's declared retention policy, which must be disclosed as part of the conformance boundary. The assessor must verify that: records in the AL have not been deleted or truncated within the declared retention period; the AL export for the assessed period is complete and contiguous; and the immutable storage export (where required at CL-02 and above) contains records back to the beginning of the declared retention period with unbroken chain continuity.

7.4 Sampling Strategy for Audit Validation

For large-scale deployments where the AL contains millions of records per day, full-chain verification on every record may be computationally intensive. The following sampling strategy is permitted for CL-01 and CL-02 assessments where full verification is impractical within the assessment window. At CL-03 and CL-04, full-chain verification is required and sampling is not permitted.

This sampling strategy applies to CL-01 and CL-02 assessments only. At CL-03 and CL-04, full-chain verification is required and sampling is not permitted.

#Revocation Propagation Certification

The revocation propagation guarantee is the time-bounded commitment that a revocation event committed to the Consent Registry will be acknowledged by all Enforcement Gateway instances within a declared TTL. This guarantee is a contractual commitment to affected parties. Certification of this guarantee requires demonstrated measurement—not configuration inspection alone.

8.1 Revocation SLA Verification

Revocation SLA verification is the process of confirming that the measured revocation propagation latency does not exceed the declared TTL at the P99 percentile. SLA verification requires production metric data—not test-environment measurements. The assessor must examine the qodiqa_revocation_propagation_ms histogram from the production ML system, covering the most recent 30 days of operation at CL-01 and CL-02, and the most recent 90 days at CL-03 and CL-04.

procedure REVOCATION_SLA_VERIFY(metric_export M, declared_TTL T):

  Step 1: Verify metric export integrity
    M.signature verified against ML signing key
    M.period_start, M.period_end within assessment window

  Step 2: Per-EG-instance P99 check
    ∀ EG instance i ∈ M.instances:
      P99_i = percentile(M.latencies[i], 99)
      if P99_i > T: FAIL — SLA violation at EG instance i
        record: instance_id=i, P99=P99_i, declared_TTL=T, violation_delta=P99_i-T

  Step 3: Worst-case P99 check
    P99_max = max(P99_i for all i)
    if P99_max > T: FAIL — aggregate SLA violation
    if P99_max > T * 0.9: WARNING — operating within 10% of TTL ceiling

  Step 4: Event count validation
    total_events = count(M.events)
    if total_events < minimum_events_threshold: INCONCLUSIVE
      minimum_events_threshold = max(1000, estimated_daily_revocations × period_days × 0.1)

  Step 5: Conservative mode activation record
    Query AL for CONSERVATIVE_MODE_ACTIVATED records in assessment period
    Each CONSERVATIVE_MODE_ACTIVATED record must have a corresponding
    CONSERVATIVE_MODE_RESOLVED record within the same TTL window
    Unresolved conservative mode records are a SLA certification failure

  Pass criterion: all P99_i ≤ T; event count ≥ threshold;
    no unresolved CONSERVATIVE_MODE_ACTIVATED records

8.2 TTL Boundary Enforcement

TTL boundary enforcement testing verifies that the system enforces the TTL boundary as a hard constraint, not a soft target. The test must verify that no PERMIT is issued for a consent_id whose revocation was committed at time T_rev at any EG instance after T_rev + TTL, regardless of cache state or propagation lag. This invariant must hold under load, under network stress, and immediately following an EG restart.

• At T_rev, commit revocation of C. At T_rev + TTL + 1s, submit a request for C at all EG instances. Verify all instances return DENY.
• Verify that EG instances for which propagation was delayed beyond TTL activated conservative mode before the TTL expired and not after.
• Verify that requests submitted between T_rev and T_rev + TTL are classified correctly: PERMITs before revocation reached the EG are acceptable; PERMITs after revocation reached the EG are failures.
• Restart an EG instance at T_rev + TTL/2. Verify that the restarted instance does not issue a PERMIT for C—even before it has received the propagated revocation—by requiring a fresh CR read on restart before resuming enforcement.

8.3 Stale Registry Detection

Stale registry detection testing verifies that the CR cache correctly expires and that stale ACTIVE states are not served beyond their cache TTL. The test simulates a scenario where the CR network is transiently unavailable, after which the cache TTL expires and the EG must either re-query CR or deny due to unavailability—and must not serve the stale ACTIVE state beyond the cache TTL bound.

8.4 Time-Bound Validation Procedure

procedure TIME_BOUND_VALIDATION(consent_id C, declared_TTL T, n_EG_instances K):

  Precondition: C.state = ACTIVE; all K EG instances operational

  Phase A — Baseline (t = 0 to t = 60s):
    Submit 10 requests per EG instance; verify all PERMIT
    Record baseline latencies and AL record timestamps

  Phase B — Revocation Commit (t = 60s):
    T_rev = now()
    Commit revocation of C via RS; record T_rev precisely (monotonic clock)
    RS emits revocation event to all K EG instances

  Phase C — Window Monitoring (t = 60s to t = 60s + TTL):
    Every 5s: submit one request to each EG instance
    Record: (EG_instance_id, request_time, decision, AL_record)
    Any PERMIT after T_rev is acceptable only if request_time < T_rev + propagation_lag_i

  Phase D — Post-TTL Boundary (t = 60s + TTL + 1s):
    Submit 5 requests to each EG instance
    Assert: ALL decisions = DENY with reason = TOKEN_REVOKED
    Assert: zero PERMITs across all K instances after T_rev + TTL
    If any PERMIT: FAIL — TTL boundary violated at instance i

  Phase E — Measurement
    For each EG instance i: propagation_lag_i = first_DENY_at_i - T_rev
    Verify: ∀ i: propagation_lag_i ≤ T
    Record: P50, P95, P99 across all instances

  Evidence: full AL export for C over [T_rev - 60s, T_rev + TTL + 60s];
    metric export for revocation_propagation_ms covering Phase C

#Certification Authority Model

Certification authority is the organizational and procedural structure through which a certification claim is evaluated and affirmed. This Framework defines three authority pathways. Each pathway produces a different claim type with different independence and credibility properties. The authority pathway must be declared as part of every public conformance statement.

9.1 Internal Self-Attestation

Internal self-attestation is the process by which a deploying organization assesses its own deployment against this Framework's requirements, produces the required evidence, and issues a Declared Conformance claim. Internal self-attestation is permitted at CL-01 and CL-02. It is not permitted at CL-03 or CL-04.

An internal self-attestation is valid only if: the assessment is performed by personnel who were not responsible for the design or implementation of the deployment being assessed; the evidence package is reviewed by a technical lead independent of the assessment team; and the resulting conformance claim is documented internally with the evidence package retained for at least the duration of the certification validity period plus six months.

9.2 Independent Third-Party Attestation

Independent third-party attestation is the process by which a qualified assessor not affiliated with the deploying organization reviews the evidence package and, where required by the certification level, executes additional verification procedures. A third-party attestation produces a Verified Conformance claim. Third-party attestation is required for CL-02 claims submitted to the public registry, and is the minimum pathway for CL-03.

9.3 Accredited Certification Bodies

An accredited certification body (ACB) is an organization that has established formal procedures for conducting QODIQA certification assessments, employs or contracts qualified assessors, maintains assessment records, and issues Certified Conformance claims. ACBs are required for CL-04 certification and are an option for CL-03.

An ACB must satisfy the following structural requirements: independent governance with no financial dependency on the deploying organizations it certifies; documented assessment procedures consistent with this Framework; assessor qualification standards at least as rigorous as §9.2; a formal certification revocation procedure; and public disclosure of the certification methodology used. An ACB that fails to satisfy any of these requirements may not issue claims under this Framework.

9.4 Conflict-of-Interest Rules

The following relationships between an assessor or ACB and a deploying organization are disqualifying and require disclosure to any party relying on the certification claim: equity ownership or financial interest in the deploying organization; provision of implementation services, architecture design, or infrastructure components to the deployment under assessment; participation in the design or specification of the deployment's enforcement infrastructure; and any relationship that would create an incentive for the assessor to produce a positive certification outcome regardless of evidence.

When a conflict of interest is discovered after a certification has been issued, the certification must be suspended pending review. The deploying organization must be notified immediately. The certification may be reinstated only after a conflict-free assessor repeats the assessment from the original evidence package.

9.5 Certification Revocation Procedure

A certification issued under this Framework may be revoked under the following conditions: evidence of a boundary-breaking event (as defined in §2.3) that has not triggered re-certification; discovery that the evidence package contained fabricated, altered, or retroactively constructed artifacts; discovery of a conflict of interest that was not disclosed; a Class 0 integrity breach in the certified deployment that has not been resolved and re-assessed; and failure to renew within the required renewal interval.

Revocation is an administrative action, not a punishment. When a certification is revoked, the deploying organization must update all public conformance statements to reflect the revocation within 48 hours. The revocation must be recorded in the public registry alongside the original certification entry. A revoked certification may be reinstated through a complete re-assessment under the applicable certification level requirements.

#Renewal and Continuous Compliance

Certification is a time-bounded claim. A certification issued today does not attest to the conformance of the deployment in twelve months. The enforcement infrastructure will evolve; policy versions will change; components will be updated; infrastructure will be modified. Renewal procedures ensure that the certification claim remains an accurate representation of the deployment's current conformance state.

10.1 Certification Validity Period

10.2 Trigger Events for Re-Certification

The following events require re-certification before the next scheduled renewal, regardless of how recently the previous certification was issued. A boundary-breaking event overrides the validity period.

• Change in deployment topology—including addition, removal, or relocation of any canonical component
• Major version upgrade of any enforcement-path component (EG, PE, CR, AL, AE)
• Change in the declared revocation TTL, in any direction
• Change in the audit ledger infrastructure, including storage system replacement, partition restructuring, or export mechanism change
• Change in the key hierarchy—including root key re-establishment, intermediate key replacement, or AE signing key algorithm change
• A Class 0 integrity breach event that required forensic review and remediation
• Policy version change that introduces new rule categories not present in the previous assessed version
• Discovery of a conformance failure in production that was not detected by the prior assessment

10.3 Version Migration Requirements

When the QODIQA corpus is revised and new normative versions of the Core Standard, the 68-Point Framework, or the Implementation Playbook are published, a version migration window is declared. During the migration window, certifications issued against the prior version remain valid. After the migration window closes, certifications must be renewed against the new version requirements. The migration window duration will be defined in the corpus revision notice; it will not be less than six months.

A deployment that is certified against an earlier version of the QODIQA corpus and that wishes to claim certification against a newer version must complete a full re-assessment against the new version requirements. Delta assessments are not sufficient for version migration; the new version may introduce requirements that interact with previously assessed controls in ways that require fresh evaluation.

10.4 Revocation of Certification Conditions

Certification revocation is distinct from certification expiry. Expiry is a scheduled event at the end of the validity period. Revocation is an unscheduled event triggered by evidence that the certified deployment is no longer conformant, regardless of position within the validity period. The following conditions mandate revocation initiation within 72 hours of discovery:

• A Class 0 integrity breach—confirmed replay, ledger chain break with external modification evidence, unauthorized CR write, or policy mutation post-freeze—that has not been remediated and re-assessed
• Evidence that the evidence package submitted for certification contained fabricated test results, retroactively constructed artifacts, or timestamps inconsistent with the claimed test execution window
• Discovery that the assessor or ACB had a disqualifying conflict of interest not disclosed at the time of assessment
• A boundary-breaking event (§2.3) that has not triggered re-certification within 30 days of the event
• Deployment of a component version that the deploying organization has determined introduces a regression in conformance but that has not yet been assessed
• A public security disclosure affecting a cryptographic primitive or key management component in the certified deployment, where the deploying organization has not demonstrated that the affected component has been replaced or mitigated
• Failure to renew within the maximum renewal interval plus a 30-day grace period

Revocation does not delete the certification history. All revoked certifications remain in the public registry with their revocation reason code and the date of revocation. A deploying organization that disagrees with a revocation determination by an ACB may request a review by a second ACB; the original certification remains SUSPENDED (not REVOKED) during the review period. If the review ACB concurs with the original revocation determination, the status changes to REVOKED and the review outcome is archived alongside the original certification record.

#Public Registry Model

The public certification registry is the authoritative record of all QODIQA conformance claims that have been submitted for public listing under the Verified or Certified claim types. It is a transparency instrument, not a marketing channel. Its purpose is to allow relying parties to independently verify conformance claims made by deploying organizations without depending on the deploying organization's own representations.

11.1 Registry Structure

Each registry entry must contain the following mandatory fields. No entry may be published without all mandatory fields. Optional fields may be included where applicable.

11.2 Transparency Requirements

Registry entries must be publicly queryable by registry_id and by deployment_id. The current status of any entry must be returned within 24 hours of a status change. REVOKED entries must remain in the registry indefinitely—they are not removed on revocation. The registry must disclose the corpus version and claim type for every entry so that relying parties can assess the scope and independence of the conformance claim.

Registry entries do not disclose the content of the evidence package, the detailed test results, or any internal deployment information. The evidence package hash is published so that a relying party who has been provided the evidence package by the deploying organization can verify its authenticity. The registry is not a substitute for direct evidence review by relying parties with specific assurance needs.

11.3 Registry Integrity

The registry itself must maintain an append-only record of all status changes, with timestamps and reason codes for each change. A registry operator that cannot demonstrate the integrity of its status change history is not operating a conformant public registry under this Framework. The registry integrity record must be independently verifiable by the deploying organization for entries pertaining to its deployments.

11.4 Version Disclosure

The public registry must disclose, for every entry, the exact QODIQA corpus version against which the deployment was assessed. Corpus version disclosure must be specific to the named document versions—it is not sufficient to state "QODIQA Core" without specifying the version number. Where the assessment covered multiple corpus documents (e.g., both the Core Standard and the 68-Point Framework), both versions must be disclosed separately in the registry entry.

Version disclosure enables relying parties to determine whether a certification was conducted against the current version of the corpus, an earlier version, or a version that has since been superseded by a normative revision. A relying party must be able to assess, from the registry entry alone and without additional information from the deploying organization, the following: the exact normative requirements the deployment was assessed against; whether those requirements have been superseded; and, if superseded, how long ago the superseding version was published. The registry must provide version lineage information sufficient to support this determination.

#Institutional Closing Statement

This Framework completes the QODIQA corpus by providing the assurance layer that makes the corpus's normative requirements verifiable. A standard without a certification framework is a set of claims that cannot be independently substantiated. A certification framework without a technically rigorous standard to certify against is a procedural shell with no normative content. The QODIQA corpus requires both, and this Framework is the second half of that pair.

The certification anchor—the deterministic certification invariant evaluate(C, P) = replay(C, P)—is not a performance metric and not a statistical property. It is a structural requirement: the enforcement function must be pure. If it is not pure, the entire accountability model built on top of it collapses. Certified conformance under this Framework is evidence that it is pure, for the assessed deployment, at the assessed time, against the assessed policy version. Nothing more and nothing less.

12.1 Corpus Alignment Statement

This Certification Framework (QODIQA-CERT-2026-001 v1.0) is normatively subordinate to and must be read in conjunction with: QODIQA — Consent as Infrastructure for Artificial Intelligence Technical Whitepaper — Version 1.0; QODIQA — 68-Point Enforcement Framework for Deterministic Runtime Consent Enforcement — Version 1.0; QODIQA — Core Standard for Deterministic Runtime Consent Enforcement — Version 1.0; QODIQA — Implementation Playbook for Deterministic Runtime Consent Enforcement — Version 1.0. In the event of conflict between this Framework's procedural specifications and the enforcement semantics of the foregoing documents, the foregoing documents prevail. This Framework is authoritative for all matters of certification procedure, evidence specification, and attestation pathway.

#Certification Lifecycle

Certification under this Framework is not a one-time event. It is a continuing compliance state that must be actively maintained through a structured lifecycle of assessment, surveillance, and renewal. A certification claim is valid only for the specific deployment configuration, policy version, and assurance level against which it was issued—and only for the duration of its declared validity period. Any departure from the assessed configuration that is not captured and re-evaluated in a subsequent assessment constitutes an unmanaged deviation from the certified state.

13.1 Certification Lifecycle Phases

13.2 Certification as a Continuing Compliance State

The lifecycle model above reflects a fundamental principle of this Framework: certification status is not a fixed property of a deployment—it is a time-bounded, configuration-specific, evidence-backed assertion that is continuously subject to invalidation. A deployment that was conformant at the time of certification may become non-conformant through any of the following: changes to the enforcement architecture without reassessment; policy version updates that alter enforcement semantics without re-verification; key rotation events that are not captured in the audit ledger; infrastructure migrations that alter component isolation properties; or surveillance findings that reveal unresolved deviations.

Relying parties must treat a certification claim as a living assertion, not a historical record. The public registry defined in Section 11 is the authoritative source of current certification status. A certificate that appears in the registry as active and unexpired, against a deployment configuration that matches the current operational state, is a valid certification claim. A certificate that is expired, suspended, or revoked—or that was issued against a configuration that has materially changed—is not valid evidence of current conformance regardless of when it was originally issued.

#Certification Assessment Procedure

Certification under this Framework requires verifiable runtime enforcement—not policy declarations, architectural diagrams, or vendor attestations. The assessment procedure is structured to produce evidence that is independently reproducible: an assessor who was not present at the original assessment must be able to re-derive the certification determination from the archived evidence package alone. Any assessment that does not produce a self-contained, independently verifiable evidence package does not satisfy the procedural requirements of this Framework.

14.1 Structured Evaluation Process

The assessment procedure is organized into six sequential evaluation stages. Each stage must be completed before the subsequent stage begins. A finding of non-conformance at any stage may be grounds for suspension of the assessment, depending on the severity classification of the finding and the certification level being sought.

14.2 Required Certification Evidence

The following table defines the standard artifact categories required during certification. Each artifact category must be represented in the evidence package by at least one artifact that satisfies the integrity and provenance requirements for the target certification level. Artifact categories marked as mandatory at a given level must be present; artifact categories marked as conditional must be present if the relevant system component or configuration is within the declared conformance boundary.

14.3 Certification Process Overview

The following diagram illustrates the sequential flow of the certification process from initial application through ongoing surveillance and renewal. Each stage corresponds to a lifecycle phase defined in Section 13.1. The diagram is intended to provide a navigational overview of the process for applicants and relying parties; the normative procedural requirements are defined in Sections 13, 14.1, and 14.4.

14.4 Certification Suspension and Revocation

Certification status must be withdrawn if deterministic enforcement can no longer be verified for the certified deployment. Suspension and revocation are not disciplinary actions—they are accurate representations of the deployment's current conformance state. A certification authority that maintains active certification status for a deployment that has materially departed from its certified configuration is not administering this Framework; it is issuing misleading assurance claims.

The following conditions constitute grounds for immediate certification suspension, pending investigation and remediation assessment:

Following suspension, the deploying organization has a defined remediation window to resolve the suspension trigger and submit evidence of remediation for assessor review. If remediation is confirmed, the suspension is lifted and the certificate is reinstated with an updated surveillance schedule. If remediation is not completed within the remediation window, or if the investigation reveals that the trigger condition reflects a deeper conformance failure, the certificate is revoked.

Revocation is permanent. A revoked certificate cannot be reinstated. A new certification assessment is required to establish a new conformance claim. Revocation records are retained in the public registry and are not removed upon subsequent recertification. Relying parties must be notified of revocation through the registry notification mechanism defined in Section 11.

#Document Status and Classification