QODIQA Audit and Evidence Generation Model
for Runtime Consent Enforcement

1.1 Architectural Position

The audit subsystem occupies a co-terminal position within the QODIQA enforcement pipeline. It does not precede enforcement and does not follow enforcement as a downstream side effect. It operates as a co-process that captures the full computational context of each enforcement event before that context is released. This co-terminal positioning ensures that the evidence record and the enforcement decision share an identical view of system state at the moment of evaluation.

The audit subsystem reads from the same frozen context that the Enforcement Gateway uses to evaluate policy. It does not derive evidence from the enforcement output alone, which would produce an incomplete record. It captures the full input contract, the resolved consent state, the applicable policy version, the evaluation result, and the enforcement outcome as a single composite artifact.

1.2 Relationship with the Enforcement Gateway

The Enforcement Gateway is the component within QODIQA that applies policy rules to a frozen evaluation context and produces a deterministic enforcement decision. The audit subsystem is its mandatory partner. The Gateway produces the decision; the audit subsystem produces the proof that the decision was made correctly, from a specific set of inputs, under a specific policy version, at a specific time.

The relationship is not hierarchical. The audit subsystem does not validate the Gateway's decision. It records it. Validation of the decision is the responsibility of downstream verification processes, which operate against the evidence record. The audit subsystem is the source of truth for those verification processes. Its integrity is therefore a prerequisite for any external audit or compliance claim.

1.3 Trust Boundary Implications

The audit subsystem operates within the QODIQA trust boundary. Its outputs, once committed to the append-only log, are considered authoritative records of enforcement history. External systems, auditors, regulatory bodies, and certification authorities that interact with QODIQA evidence records must treat those records as the canonical representation of system behavior.

The trust boundary requires that the audit subsystem be isolated from the components it observes. The subsystem must not be reachable from the AI inference path in a way that would permit the inference path to alter, suppress, or selectively produce evidence records. Isolation is a structural requirement, not a configuration option.

1.4 System Boundary and Trust Isolation

The QODIQA trust boundary defines the set of components whose operation is governed by and accountable to the QODIQA specification. Components inside the boundary are subject to the full set of determinism, immutability, and integrity requirements defined in this corpus. Components outside the boundary are treated as external principals that interact with QODIQA through defined interfaces and whose behavior QODIQA does not assume or control.

The boundary is not a network perimeter; it is an accountability perimeter. Components inside the boundary must be operated, monitored, and auditable by the deploying organization. Any component that can influence an enforcement decision or an evidence record must be inside the boundary or its influence must be mediated through a defined, auditable interface.

The fundamental isolation rule is absolute: an AI system must not be able to influence the generation of the evidence record that corresponds to its own enforcement event. This prohibition extends to indirect influence through shared resources, side channels, timing manipulation, or administrative access to the audit subsystem.

2.1 Immutability

Evidence records, once committed to the audit log, must not be altered, updated, or deleted under any operational condition. Immutability is absolute. It applies to the record content, the record metadata, and the record's position within the log sequence. Systems that expose mutation interfaces to the audit log, even for the purpose of error correction, do not conform to this specification.

2.2 Verifiability

Every evidence record must be independently verifiable. Verifiability means that a party in possession of the record, its associated cryptographic proof, and the applicable policy and consent state versions can confirm that the record accurately represents the enforcement decision that occurred. Verifiability does not require access to the live QODIQA system. It requires only the record itself and the referenced immutable artifacts.

2.3 Non-Repudiation

Evidence records must be cryptographically signed such that the producing system cannot later deny having made the recorded decision. Non-repudiation requires that the signing key be controlled by the QODIQA enforcement subsystem and that the signature be verifiable against a published public key or certificate chain. Key management practices that permit retroactive alteration of signing authority are incompatible with this principle.

2.4 Completeness

The audit log must contain a complete record of every enforcement event processed by the system. Gaps are not acceptable. A missing record is not an absence of evidence; it is evidence of a gap in audit coverage, which is itself an audit finding. Implementations must detect and report gaps automatically. Manual gap identification is insufficient.

2.5 Time Consistency

Evidence records must include timestamps derived from a monotonic, tamper-evident time source. Time consistency means that the ordering of records in the audit log is consistent with the actual temporal ordering of enforcement events. Systems that rely on client-supplied timestamps, mutable system clocks, or network time sources subject to manipulation do not satisfy this principle.

3.1 Definition of Evidence

An evidence record within QODIQA is a composite artifact that contains: the identity of the enforcement event that produced it; the complete input contract presented to the Enforcement Gateway; the resolved consent state at the moment of evaluation; the version-pinned policy that was applied; the intermediate evaluation trace; the final enforcement decision; and the cryptographic linkage that binds this record to the preceding record in the append-only log.

Evidence is generated at enforcement time, not retrospectively. It captures the state as it existed during evaluation. Post-hoc reconstruction of evidence is not permitted and would not constitute evidence under this specification. The evidence record is produced within the same atomic operational unit as the enforcement decision itself.

3.2 Evidence Types

The QODIQA evidence model recognizes four canonical evidence types. Each type addresses a distinct dimension of the enforcement event and together they constitute the complete evidentiary record of a QODIQA enforcement lifecycle.

4.1 Event Class: Inference Request Received

This event is emitted when a conforming AI system presents an intent declaration to the QODIQA Enforcement Gateway. It represents the initiation of an enforcement transaction and marks the beginning of the audit record chain for that transaction.

4.2 Event Class: Policy Evaluation

This event is emitted upon completion of the policy evaluation phase. It records the policy version applied, the evaluation trace, and the intermediate result prior to the final enforcement decision. Policy evaluation events provide the traceability necessary to verify that the correct policy was applied to the correct input.

4.3 Event Class: Consent Lookup

This event is emitted when the Enforcement Gateway queries the consent registry. It records the exact consent state retrieved, its version, its temporal validity, and the resolution result. Consent lookup events are the evidentiary basis for consent verification proofs and are required for any claim that a consent condition was satisfied at the time of enforcement.

4.4 Event Class: Enforcement Decision

This event records the final deterministic enforcement decision produced by the Enforcement Gateway. It is the primary audit artifact and constitutes the authoritative record of system authorization behavior. Every enforcement transaction that reaches a terminal state must produce exactly one Enforcement Decision event.

4.5 Event Class: Block / Allow Outcome

This event is emitted by the system component that enforces the Enforcement Gateway's decision at the execution layer. It confirms that the decision was communicated to, and acted upon by, the downstream system. Block/Allow Outcome events close the enforcement transaction record and provide evidence that the decision was not merely recorded but actually applied.

5.1 Canonical Schema

Each evidence record is represented as a JSON object conforming to the QODIQA Evidence Schema v1.0. The schema is published as part of the QODIQA standard corpus and is referenced by SHA-256 content hash in each evidence record's metadata block. This self-referential schema pinning ensures that the schema version used to produce a record is unambiguously identifiable, regardless of subsequent schema revisions.

The canonical schema defines a two-part structure: a mandatory metadata envelope and a mandatory payload body. The metadata envelope contains fields common to all event classes. The payload body is event-class-specific and contains the fields defined in the Audit Event Taxonomy.

{
  "qodiqa_schema_version": "1.0",
  "qodiqa_schema_hash":    "<SHA-256 hash of QODIQA-EVIDENCE-SCHEMA-v1.0>",
  "metadata": {
    "event_id":           "<UUID v4>",
    "event_class":        "<canonical event class identifier>",
    "transaction_id":     "<UUID v4>",
    "timestamp_utc":      "<ISO 8601 UTC timestamp, nanosecond precision>",
    "log_sequence_num":   <monotonic integer, unique within log partition>,
    "prev_event_hash":    "<SHA-256 of canonical serialization of preceding record>",
    "producer_id":        "<stable identifier of the QODIQA subsystem instance>",
    "producer_signature": "<ECDSA-P256 signature over this record's canonical form>"
  },
  "payload": {
    // event-class-specific fields as defined in Section 4
  }
}

5.2 Field-Level Definitions

All timestamp fields use ISO 8601 extended format in the UTC timezone with nanosecond precision. The format is: YYYY-MM-DDTHH:MM:SS.nnnnnnnnnZ. Timestamps that do not conform to nanosecond precision are not accepted by the QODIQA audit log ingestion interface.

All hash fields contain the hexadecimal encoding of a SHA-256 digest, lowercase, without prefix, exactly 64 characters in length. Hash fields that contain uppercase characters, prefix notation such as sha256:, or incorrect length are rejected.

All signature fields contain the Base64url encoding of an ECDSA-P256 signature over the canonical serialization of the record, as defined in Section 5.3. Signatures are computed after all other fields in the record have been finalized. The producer_signature field is excluded from the data over which the signature is computed; it contains the result of that computation.

All UUID fields conform to RFC 4122 version 4 format. UUIDs are represented as lowercase hyphenated strings. UUIDs generated by the QODIQA system must exhibit cryptographically adequate randomness and must not be predictable or sequential in a way that would permit pre-commitment attacks.

5.3 Deterministic Serialization

The canonical serialization of a QODIQA evidence record is a deterministic JSON encoding produced according to the following rules, in order: all object keys are sorted lexicographically in ascending byte order; all string values are encoded as UTF-8; no insignificant whitespace is included; all floating-point values are expressed in their shortest representation that round-trips; boolean values are lowercase true or false; null values are expressed as null; array element order is preserved as specified in the schema.

Deterministic serialization is the prerequisite for reproducible hash computation and signature verification. Any deviation from these rules produces a different serialization, a different hash, and an invalid signature. Implementations must validate that their serialization produces byte-identical output for a given record structure before being considered conforming.

The canonical serialization specification is not subject to interpretation. It is a precise algorithmic procedure. Implementations must reference the QODIQA Canonical Serialization Test Vector Suite, distributed with the standard corpus, to validate their serialization behavior before deployment.

6.1 Hash Chaining

Each evidence record includes the SHA-256 hash of the immediately preceding record in the audit log partition as the value of the prev_event_hash field. This hash chain binds the sequence of records such that any modification, insertion, or deletion of a record invalidates the hashes of all subsequent records. The chain is broken at the log partition boundary; the genesis record of each partition contains null in the prev_event_hash field.

Hash chaining provides tamper detection at the log level. It does not, by itself, prevent tampering; it ensures that tampering is detectable. The detection capability depends on the verifier having access to at least one authentic hash value, which is provided by the external anchoring mechanism described in Section 6.4.

for each record R[i] in partition where i > 0:
  expected_prev_hash = SHA-256(canonical_serialize(R[i-1]))
  assert R[i].metadata.prev_event_hash == expected_prev_hash,
    "Chain integrity failure at position i: expected hash does not match"

6.2 Tamper-Evidence Guarantees

The hash chain provides a strong tamper-evidence guarantee: any modification to any record in a partition makes the chain verifiably inconsistent from the point of modification forward. This guarantee holds under the assumption that the attacker cannot recompute valid SHA-256 hashes faster than the system appends new records.

The tamper-evidence guarantee does not extend to: truncation of the log from the end; suppression of records prior to their commitment; or replacement of the entire partition with a freshly constructed chain. These attack vectors are addressed by external anchoring and integrity monitoring, described below.

6.3 Signing Requirements

Each evidence record is individually signed by the QODIQA Enforcement Gateway's signing key using ECDSA with the P-256 curve and SHA-256 as the hash function. The signature is computed over the canonical serialization of the complete record, excluding the producer_signature field itself.

The signing key must be an asymmetric key held within a hardware security module or equivalent trusted execution environment. Software-only key storage does not satisfy this requirement for production deployments. The corresponding public key must be published through the QODIQA Certification Registry under the deploying organization's certified entry. Key rotation must follow the key management procedures specified in the QODIQA Security and Cryptographic Profile.

Signatures must be verified before any evidence record is accepted by the audit log ingestion interface. Records that fail signature verification are rejected and the rejection is itself recorded as a system integrity event.

6.4 Optional External Anchoring

Implementations may optionally anchor the audit log to an external tamper-evident structure, such as a Merkle tree whose root is periodically published to an immutable external record, a transparency log service, or a distributed ledger. External anchoring provides tamper-evidence guarantees that extend beyond the organizational boundary and are verifiable by parties who do not have access to the QODIQA system itself.

When external anchoring is employed, the anchor reference must be included in the log partition metadata and associated with the range of records covered by the anchor. Anchoring does not replace the hash chain or individual record signatures; it supplements them with an additional, externally verifiable integrity proof.

The use of external anchoring is strongly recommended for deployments subject to regulatory audit, cross-organizational enforcement, or third-party certification. Anchoring frequency should be calibrated to the acceptable window of undetected tampering for the deployment context.

7.1 Strict Append-Only Behavior

The audit log must expose only append operations to the components that write evidence records. Read and append operations may be available to authorized consumers. Update, delete, and truncate operations must not be exposed through any interface, including administrative interfaces, backup and restore procedures, and emergency access paths.

Implementations must document how append-only behavior is enforced at the storage layer and must demonstrate that no code path within the QODIQA system or its dependencies can produce a mutation of committed records. This documentation is required as part of the QODIQA Certification Framework conformance evidence package.

7.2 Ordering Guarantees

Records within a log partition must be ordered by their monotonic timestamp and log sequence number. The log sequence number is a monotonically increasing integer, unique within a partition, assigned at the time of record commitment. The combination of partition identifier and log sequence number provides a globally unique, stable position reference for each record.

The ordering guarantee requires that the audit log ingestion interface reject records with timestamps or sequence numbers that violate monotonicity. Out-of-order submissions, whether due to clock skew, network reordering, or operational errors, must be rejected and the rejection recorded as a system integrity event. Any implementation that accepts out-of-order records without rejection is non-conformant.

7.3 Replay Consistency

The audit log must support deterministic replay: given the same sequence of evidence records, any compliant QODIQA verifier must produce the same verification result. Replay consistency requires that all state referenced by evidence records, including policy versions and consent state versions, remain available and immutable for as long as the records that reference them are retained.

Implementations must maintain version-pinned copies of all policy and consent state artifacts referenced by audit records. These copies must be stored in an immutable object store and must not be subject to garbage collection, compaction, or expiration policies that would render historical records unverifiable.

8.1 Evidence Access Model

Access to evidence records is governed by a role-based authorization model that is separate from, and independent of, the QODIQA Enforcement Gateway's authorization model. The audit subsystem must not process its own access requests through the Enforcement Gateway; doing so would create a circular dependency that could compromise audit completeness.

Three access roles are defined. The Audit Reader role provides read access to individual records by event_id or transaction_id. The Partition Verifier role provides read access to complete partitions and the metadata necessary for hash chain verification. The Certification Auditor role provides read access to all evidence and referenced artifacts necessary to perform a complete conformance audit.

Access to evidence records containing consent subject references must be controlled such that only parties with a legitimate audit purpose can retrieve records associated with a specific subject. General-purpose search and retrieval interfaces must not permit enumeration of consent subject references.

8.2 Verification Flows

Evidence verification consists of two distinct operations that may be performed independently or in combination. Record verification confirms that a specific evidence record is authentic, unmodified, and was produced by the QODIQA system. Chain verification confirms that a sequence of evidence records forms an unbroken, tamper-evident chain.

Record verification proceeds as follows: retrieve the evidence record by event_id; retrieve the signing public key associated with the producer_id at the record's timestamp; compute the canonical serialization of the record excluding the producer_signature field; verify the ECDSA-P256 signature against the serialization using the retrieved public key; confirm that the timestamp falls within the validity period of the signing key certificate.

Chain verification proceeds as follows: retrieve all records in the partition ordered by log_sequence_num; for each record at position i greater than zero, compute SHA-256 of the canonical serialization of the record at position i minus one; confirm that the computed hash matches the prev_event_hash field of the record at position i; report any mismatch as a chain integrity failure with the position and the two records involved.

8.3 Third-Party Validation Capability

A conforming QODIQA implementation must support third-party validation without requiring the validator to have operational access to the QODIQA system. Third-party validation is enabled by the combination of: the complete evidence record, including all referenced artifact hashes; the published signing public keys of the QODIQA deployment; the immutable copies of all policy and consent state versions referenced by the record; and, if external anchoring is employed, the anchor proof for the relevant partition range.

Third-party validators must be able to perform both record verification and chain verification using only these artifacts. A QODIQA deployment that requires validator access to live system APIs to complete verification does not satisfy the third-party validation requirement.

Missing Logs

A missing log is defined as the absence of one or more expected evidence records for enforcement events that are known to have occurred. Missing logs may result from audit subsystem failures, storage failures, record ingestion rejections, or software defects. In all cases, the absence of an expected record is itself an audit-significant event that must be recorded and reported.

The QODIQA audit subsystem must implement continuous completeness monitoring that detects gaps in the log sequence number series within each partition. Detected gaps trigger an automatic integrity alert and, where the gap is attributable to a known failure, a gap record is appended to the log documenting the nature and extent of the missing coverage.

Corruption Scenarios

Corruption of an evidence record is detected through hash chain verification and individual record signature verification. When corruption is detected, the corrupted record and all subsequent records in the partition must be flagged. The original, pre-corruption content of records cannot be recovered from the audit log itself; recovery requires resort to external backup or anchor proofs.

Implementations must maintain isolated, cryptographically protected backup copies of evidence records that are not reachable through the same administrative paths as the primary audit log. Backup copies must be verified on a scheduled basis to ensure they remain uncorrupted and complete.

Partial Evidence

Partial evidence occurs when an enforcement transaction produces some but not all of its expected events. For example, an EVT-001 record may exist without a corresponding EVT-004 or EVT-005 record, indicating that the transaction did not reach a terminal state. Partial evidence records are retained in the audit log and flagged as incomplete transactions.

Incomplete transactions are ambiguous from an audit perspective: they demonstrate that an enforcement attempt was made but do not establish the outcome. Implementations must report incomplete transactions in audit summaries and must not treat them as authorization evidence for either direction.

Required Fail-Closed Behavior

When the audit subsystem is unavailable or unable to commit a new evidence record, the Enforcement Gateway must deny all pending enforcement requests. The Gateway must not issue authorization decisions that cannot be simultaneously recorded as evidence. This fail-closed behavior is absolute and cannot be overridden by operational policy, service level agreements, or administrative instruction.

The fail-closed requirement means that audit subsystem availability is on the critical path for AI system operation. Implementations must design the audit subsystem for high availability commensurate with the availability requirements of the AI systems it serves. Single-point-of-failure architectures in the audit path are incompatible with the QODIQA reliability standard.

What Is Logged

Evidence records must contain sufficient information to enable independent verification of the enforcement decision. This includes: the intent declaration structure, expressed in terms of purpose, scope, and duration categories, without raw data content; the consent subject reference, expressed as an opaque, non-reversible identifier that does not encode personal information; the consent resolution result and the attributes that determined it, without including the raw consent record content; and the enforcement decision and its basis, without including the content of the AI inference request or response.

The audit record documents the authorization event, not the data processing that the authorization event permits or denies. The content of the AI inference, the personal data processed, and the model outputs are outside the scope of the audit log and must not be included in evidence records.

What Is Not Logged

The following categories of information must never appear in QODIQA evidence records under any circumstances: raw personal data of any kind; AI model inputs and outputs; consent subject identifiers that can be linked to natural persons without access to a separately held mapping; data category labels that, in combination, constitute a re-identification risk; and system credentials, API keys, or internal network addresses.

Redaction Constraints

Redaction of evidence records after commitment is prohibited by the immutability principle. Implementations must ensure that records are produced in compliant form at the time of generation. There is no post-commitment redaction mechanism, and no post-commitment redaction mechanism may be implemented.

If an evidence record is inadvertently produced containing non-compliant content, the appropriate response is to flag the record as containing a data quality defect, record the nature of the defect in a supplementary integrity event, and investigate the root cause to prevent recurrence. The record itself must not be modified, deleted, or withheld from authorized audit access.

Audit as Compliance Artifact

Certification assessors evaluating a QODIQA deployment for conformance will rely on the audit log as the authoritative record of system behavior during the assessment period. The assessor must be able to independently verify a representative sample of enforcement decisions by performing record verification and chain verification as defined in Section 8. A deployment that cannot support this verification process cannot be certified.

The completeness of the audit log is itself a conformance criterion. Deployments that exhibit unexplained gaps in their enforcement record, incomplete transactions without corresponding explanatory integrity events, or chain integrity failures that cannot be accounted for by documented system events will receive a qualified or conditional certification status.

Evidence Retention Requirements

Evidence records must be retained for a minimum retention period defined by the QODIQA Certification Framework and, where applicable, by the regulatory requirements of the jurisdiction in which the deployment operates. The minimum QODIQA retention period is seven years from the date of record commitment. Retention does not permit archival in a form that would degrade verification capability; all referenced artifacts must remain available for the full retention period.

Audit-Driven Conformance Reporting

Deploying organizations may generate automated conformance reports from the audit log that summarize enforcement activity, consent resolution rates, policy application patterns, and gap metrics over a specified period. These reports, when accompanied by the underlying evidence records and verification proofs, constitute the primary documentary basis for certification renewal and regulatory reporting.

Latency Impact

Evidence generation occurs on the critical path of the enforcement decision. The audit subsystem must produce, sign, and commit a complete evidence record before the Enforcement Gateway returns its decision to the calling system. The latency budget for evidence generation is therefore bounded by the latency requirements of the overall enforcement transaction.

QODIQA specifies a maximum evidence generation latency target of 5 milliseconds at the 99th percentile under sustained production load. This target assumes a co-located audit subsystem with local HSM access. Deployments that require network-remote audit log infrastructure must account for network latency in their latency budget and may need to design the audit path accordingly, for example through batched signing with individual pre-commitment record locking.

Implementations must monitor evidence generation latency continuously and alert when the 99th percentile exceeds 5 milliseconds. Sustained latency exceedance is a performance non-conformance that must be addressed through architectural remediation, not latency budget adjustment.

Storage Constraints

Evidence records are structured JSON objects. A typical enforcement transaction produces five event records with a combined uncompressed size in the range of 4 to 12 kilobytes, depending on policy complexity and evaluation trace depth. At high enforcement volumes, storage accumulation can be substantial.

Storage planning must account for the seven-year minimum retention requirement. At an enforcement rate of 10,000 transactions per second, the uncompressed evidence record volume is approximately 360 gigabytes per day, or approximately 920 terabytes over seven years before compression. Compression ratios of 4:1 to 8:1 are achievable on structured JSON evidence records, reducing the practical storage requirement to approximately 115 to 230 terabytes for this throughput profile. Storage estimates must be revised for each deployment based on actual enforcement rates and policy complexity.

Throughput Considerations

The audit log ingestion interface must sustain throughput commensurate with the peak enforcement rate of the deployment, with sufficient headroom to absorb burst traffic without evidence loss. Log ingestion throughput must be tested under peak load conditions as part of the pre-production conformance validation process.

Hash chain computation and signature verification at high throughput are computationally intensive operations. Implementations must benchmark their cryptographic processing capacity against their expected enforcement rates and provision sufficient compute resources to avoid cryptographic operations becoming the throughput bottleneck. Parallel verification pipelines are permitted for read operations, but write operations must maintain strict sequential ordering within each partition to preserve hash chain integrity.

What Audit Does Not Guarantee

The QODIQA audit model guarantees that enforcement decisions, once made and recorded, are preserved with verifiable integrity and cannot be silently altered or suppressed. It does not guarantee the correctness of the enforcement decisions themselves. If the policy or consent state inputs to the Enforcement Gateway are corrupted, incomplete, or fraudulently constructed, the audit record will faithfully document an incorrect decision without being able to detect the incorrectness of the inputs.

The audit model does not provide coverage for enforcement events that are entirely suppressed before reaching the audit subsystem. A compromised Enforcement Gateway that issues authorization decisions without triggering the audit path would produce no evidence records and would therefore produce no detectable audit gap until the absence of records was noticed through external means. Mitigating this risk requires architectural controls at the integration boundary, not audit system controls.

The audit model does not provide coverage for the behavior of AI systems operating downstream of an authorization decision. Once the Enforcement Gateway issues an ALLOW decision, the audit subsystem's jurisdiction ends. If the authorized AI system acts outside the scope of the authorization, that deviation occurs in a space that is not monitored by the QODIQA audit subsystem.

Explicit Limitations

The cryptographic integrity model provides tamper-evidence guarantees that depend on the security of the ECDSA-P256 signature scheme and SHA-256 hash function. Both are considered secure against current and near-term classical computing adversaries. The model does not provide quantum-resistant security guarantees. Organizations operating in threat environments where quantum adversaries are a credible concern should consult the QODIQA Security and Cryptographic Profile for guidance on migration to post-quantum cryptographic primitives.

The audit model provides a record of what the system decided; it does not provide a record of why human operators made the policy and consent configuration choices that led to those decisions. The institutional accountability for those choices rests with the humans and organizations that govern the QODIQA deployment, not with the audit subsystem.

Finally, the usefulness of the audit record is contingent on the operational practices of the deploying organization. An audit log that is never examined, whose integrity is never verified, and whose evidence is never presented to accountable parties provides no practical accountability benefit, regardless of its technical conformance. The QODIQA audit model provides the infrastructure for accountability; whether that infrastructure is used effectively is an organizational governance question outside the scope of this specification.