QODIQA Audit Readiness and
Evidence Pack

#Purpose and Scope

The QODIQA Audit Readiness and Evidence Pack is a normative component of the QODIQA standard corpus. Its purpose is to translate the determinism, auditability, and proof guarantees established in the QODIQA Technical Whitepaper into a concrete operational framework for audit preparation, evidence collection, and compliance demonstration.

Regulatory environments governing AI systems increasingly require that organizations be able to demonstrate not merely that governance policies exist, but that they are enforced at execution time in a verifiable, reproducible manner. This requirement cannot be satisfied through documentation alone. It demands a form of evidence that is structural: evidence that emerges from the system itself rather than from post hoc reconstruction.

QODIQA is designed so that audit evidence is a byproduct of correct operation. Every decision the system produces is a stable artifact with a deterministic identifier, a frozen evaluation context, and a traceable policy version. This document specifies how those artifacts are organized, retained, and presented in a format suitable for regulatory, contractual, and internal audit purposes.

The scope of this document covers: the dimensions of audit readiness applicable to QODIQA deployments; the structure and classification of evidence generated by the framework; the mapping of QODIQA system properties to obligations arising under applicable regulatory instruments; the procedural requirements for audit trail maintenance and integrity verification; the pre-audit verification checklist and decision replay protocol; the canonical structure of an evidence pack submission; and the operational practices that sustain continuous audit readiness.

This document does not address legal interpretation of regulatory obligations, implementation-specific deployment configurations, or upstream consent capture systems. Those domains are addressed in separate corpus documents as referenced in the Document Status section.

#Audit Readiness Framework

Audit readiness is not a state achieved immediately before an audit. It is a continuous operational property, maintained through the same mechanisms that ensure correct system behavior during normal operation. For QODIQA deployments, audit readiness and operational correctness are structurally equivalent: a system that enforces consent deterministically and produces stable decision artifacts is, by design, audit-ready.

The following sections define the dimensions of audit readiness, the categories of evidence that QODIQA generates, and the maturity levels against which organizations may assess their current posture.

2.1 Readiness Dimensions

Audit readiness for a QODIQA deployment is assessed across four dimensions. Each dimension corresponds to a structural property of the system rather than a procedural requirement.

Decision traceability is the ability to locate, identify, and retrieve any past decision artifact given a reference identifier, time range, actor identifier, or action type. This dimension is satisfied when the decision artifact store is queryable, retained according to policy, and structurally complete for each decision.

Consent state verifiability is the ability to demonstrate, for any past decision, that the consent state resolved at evaluation time was valid, scoped, and current. This dimension is satisfied when consent references captured in frozen evaluation contexts can be matched against consent state records with confirmed validity at the relevant timestamp.

Policy immutability is the ability to demonstrate that the policy version applied in any past decision has not been altered since that decision was recorded. This dimension is satisfied when policies are versioned with cryptographic integrity protection and version history is retained without modification.

Replay correctness is the ability to re-evaluate any past decision using its frozen context and obtain an identical outcome. This dimension is the strongest evidence of determinism and is satisfied when the replay protocol consistently produces results matching the recorded decision identity.

2.2 Evidence Categories

Evidence produced by a QODIQA deployment falls into four categories, each corresponding to a readiness dimension.

All four categories must be present and complete for an evidence pack to be considered audit-ready. Partial evidence packs, in which one or more categories are absent or incomplete, do not satisfy the structural auditability requirements of QODIQA and must not be presented to regulators or auditors as complete submissions.

2.3 Readiness Maturity Levels

The following maturity levels provide a structured assessment model for organizations evaluating their current audit readiness posture. Each level is defined by the capabilities present, not by the volume of evidence or time in operation.

Level 3 represents the target state for organizations operating QODIQA in regulated environments. Levels 1 and 2 are recognized as transitional states during deployment and maturation phases.

#Evidence Architecture

The evidence architecture of QODIQA is not an overlay applied to the system after the fact. It is a direct consequence of the architectural constraints that make the system deterministic. Because every decision is derived from an immutable, canonical set of inputs, the evidence required to verify that decision is produced at evaluation time and requires no subsequent reconstruction.

The following sections describe the structure and content of each evidence category in technical detail.

3.1 Decision Artifact Evidence

A decision artifact is the primary evidence unit of a QODIQA deployment. It is produced by the Decision Artifact Generator at the conclusion of every evaluation, regardless of outcome. Each artifact contains the following elements.

DecisionArtifact = {
    "decision_id":        str,      # SHA-256 derived, 24-char hex
    "timestamp_utc":      datetime, # Evaluation time, frozen
    "outcome":            str,      # ALLOW | DENY | ALLOW_WITH_RESTRICTIONS
    "restrictions":       list,     # If ALLOW_WITH_RESTRICTIONS
    "context_ref":        str,      # Reference to frozen EvaluationContext
    "consent_ref":        str,      # Reference to resolved ConsentState
    "policy_version":     str,      # Exact policy version applied
    "ruleset_version":    str       # Exact ruleset version applied
}

The decision_id field is deterministically derived from the canonical representation of the evaluation context and outcome. Given the same inputs, the identifier is always identical. This property enables independent verification: any auditor with access to the frozen context and outcome can recompute the identifier and confirm its authenticity without trust in the originating system.

3.2 Consent State Evidence

Consent state evidence demonstrates that the consent resolved at evaluation time was valid, current, and appropriately scoped. The frozen evaluation context captures a reference to the resolved consent record, not the record itself, ensuring that the decision artifact remains stable even if the consent state subsequently changes.

For audit purposes, organizations must be able to produce the consent state record identified by the reference in the frozen context and demonstrate that it was in a valid, non-revoked state at the evaluation timestamp. This requires that consent stores retain historical consent state, including timestamps of revocation, expiry, and scope modifications, for the full audit retention period.

ConsentStateRecord = {
    "consent_id":     str,
    "subject_id":     str,
    "purpose":        str,
    "scopes":         list[str],
    "valid_from":     datetime,
    "valid_until":    datetime,
    "revoked":        bool,
    "revoked_at":     datetime | None,
    "created_at":     datetime,
    "record_version": int
}

The audit claim that must be substantiable from this evidence is: at the time of evaluation, the referenced consent record existed, was not revoked, had not expired, and covered the purpose and scopes declared in the execution request.

3.3 Policy Version Evidence

Policy version evidence demonstrates that the rule set applied during evaluation has not been altered since the decision was recorded. Because QODIQA policies are immutable and versioned, this evidence takes the form of a policy version snapshot retained alongside its cryptographic digest.

PolicyVersionSnapshot = {
    "version":          str,
    "effective_from":   datetime,
    "effective_until":  datetime | None,
    "rules_digest":     str,     # SHA-256 of canonical rule representation
    "rules_ref":        str,     # Content-addressed reference
    "authored_by":      str,
    "approved_by":      str,
    "approved_at":      datetime
}

Policy version snapshots must be retained without modification. Any change to a policy ruleset produces a new version with a new digest. The digest of a version applied in a past decision can be recomputed from the retained rules content and compared to the recorded value, providing cryptographic proof of immutability.

3.4 Replay Verification Evidence

Replay verification evidence is produced by executing the decision replay protocol against a decision artifact and its associated frozen context. It demonstrates that the system's evaluation function is deterministic: the same inputs produce the same outcome, independent of when or where the evaluation is performed.

ReplayVerificationRecord = {
    "original_decision_id":  str,
    "replay_decision_id":    str,
    "match":                 bool,
    "replay_timestamp_utc":  datetime,
    "replay_environment":    str,
    "performed_by":          str
}

A replay verification record where match == true and both decision identifiers are equal constitutes positive proof of determinism for that decision. Systematic replay verification across a representative sample of decisions provides confidence in the correctness of the evaluation function across time and environment.

#Regulatory Compliance Mapping

The QODIQA framework is designed to be regulation-agnostic at the enforcement layer. It does not interpret law or encode regulatory obligations directly. However, its structural properties map onto obligations arising under data protection law, AI regulation, and sector-specific compliance frameworks in ways that can be demonstrated through the evidence architecture described in Section 3.

The following mappings are illustrative rather than exhaustive. Organizations operating in regulated environments must conduct their own legal and compliance analysis to confirm applicability. Translations from QODIQA system properties to regulatory obligations are presented as structural correspondences, not legal opinions.

4.1 General Data Protection Regulation (GDPR) Mapping

4.2 EU AI Act Mapping

The EU AI Act establishes obligations for providers and deployers of high-risk AI systems, including requirements for transparency, human oversight, technical documentation, and record-keeping. QODIQA's enforcement architecture maps onto several of these obligations.

4.3 Sectoral Obligations

Sector-specific regulatory frameworks in financial services, healthcare, and critical infrastructure impose additional obligations that intersect with the QODIQA evidence architecture. While comprehensive mapping across all sectoral instruments is outside the scope of this document, three structural properties are broadly applicable.

Immutable audit trails are required by financial services regulators and healthcare data protection authorities in most jurisdictions. QODIQA's decision artifacts satisfy this requirement structurally: they are produced at evaluation time, are not modifiable after creation, and carry cryptographic identifiers derived from their content.

Automated decision records are required under algorithmic accountability frameworks applicable in financial credit, insurance, and employment contexts. QODIQA's decision artifacts contain the information required to explain the factual basis of an automated decision, namely the declared intent, resolved consent state, and policy version applied, without exposing raw data or model internals.

Incident evidence preservation is required under breach notification and incident reporting frameworks. QODIQA denial records, produced when execution is refused due to consent failure or policy mismatch, constitute pre-existing evidence of enforcement activity that may be relevant to incident investigation and regulatory notification.

Organizations deploying QODIQA in regulated sectors should conduct a gap analysis between the evidence categories described in this document and the specific evidence requirements of applicable sectoral instruments, retaining the results as part of their compliance documentation.

#Audit Trail Requirements

An audit trail in the context of QODIQA is not a passive log. It is a structured, integrity-protected sequence of decision artifacts, consent state records, and policy version snapshots that collectively constitute verifiable proof of authorized AI execution over a defined period. The following sections specify the structural, retention, and integrity requirements that an audit trail must satisfy.

5.1 Structural Requirements

Every decision produced by a QODIQA deployment must generate a corresponding entry in the audit trail. There are no excluded decision types. Denials, approvals, and approvals with restrictions must all be recorded with equal completeness. Selective retention of only allow decisions is a structural failure that invalidates the audit trail.

Each audit trail entry must contain, at minimum: the complete decision artifact, the reference to the frozen evaluation context, a reference to the consent state record valid at evaluation time, and the policy version identifier with its associated digest.

Audit trail entries must be written atomically with the decision. A decision that is communicated to a downstream system without a corresponding audit trail entry is an enforcement failure. Systems must be designed so that audit trail write failures result in decision denial, not silent continuation.

5.2 Retention Policy

Audit trail retention periods must be defined prior to deployment and reviewed against applicable regulatory requirements. Where regulatory retention periods differ across applicable instruments, the longest applicable period governs.

Retention policy must be documented, version-controlled, and included in the evidence pack submitted for audit. Changes to retention policy must be recorded with effective dates and must not result in early deletion of evidence that falls within the retention period of the superseded policy.

5.3 Integrity Verification

The integrity of the audit trail must be verifiable through cryptographic means. Reliance on access controls or procedural safeguards alone is insufficient: evidence that cannot be independently verified for integrity cannot be relied upon to prove that it has not been altered.

Integrity verification is performed at two levels. At the artifact level, the decision_id field of each artifact is a deterministic function of its content. Recomputing this identifier and comparing it to the recorded value confirms that the artifact has not been modified. At the trail level, a hash chain or equivalent mechanism links audit trail entries in sequence, enabling detection of deletions or insertions that would not be detectable through individual artifact verification alone.

Integrity verification must be performed at regular intervals, not solely in anticipation of an audit. Organizations operating at maturity level 3 perform continuous automated integrity verification and produce periodic integrity attestation records as part of their evidence pack.

#Verification Procedures

The verification procedures defined in this section are executed as part of audit preparation and ongoing operational assurance. They are not substitutes for external audit; they are the internal controls that make external audit defensible.

6.1 Pre-Audit Checklist

The following checklist must be completed and documented prior to any audit submission. Each item corresponds to a structural requirement described in this document.

6.2 Decision Replay Protocol

The decision replay protocol is the primary verification procedure for demonstrating determinism. It is executed by re-evaluating a selection of past decisions using their frozen evaluation contexts and confirming that the computed decision identifiers match the recorded values.

def replay_decision(artifact: DecisionArtifact) -> ReplayVerificationRecord:
    context = load_frozen_context(artifact.context_ref)
    policy  = load_policy_version(artifact.policy_version)

    replayed_outcome = evaluate(context, policy)
    replayed_id = decision_id(context, replayed_outcome)

    return ReplayVerificationRecord(
        original_decision_id = artifact.decision_id,
        replay_decision_id   = replayed_id,
        match                = replayed_id == artifact.decision_id,
        replay_timestamp_utc = utcnow(),
        replay_environment   = current_environment(),
        performed_by         = current_operator()
    )

The protocol must be executed against a sample that is representative of the decision population for the audit period. The sample must include decisions with each outcome type (ALLOW, DENY, ALLOW_WITH_RESTRICTIONS), decisions from different policy versions, and decisions involving different actors and purposes. All replay verification records must be retained and included in the evidence pack.

6.3 Policy Immutability Check

The policy immutability check verifies that no policy version applied during the audit period has been modified after its effective date. The check is performed by recomputing the rules digest for each policy version and comparing it to the digest recorded in the policy version snapshot.

def verify_policy_version(snapshot: PolicyVersionSnapshot) -> bool:
    rules    = load_rules_content(snapshot.rules_ref)
    computed = sha256(canonicalize(rules))
    return computed == snapshot.rules_digest

Any version for which the computed digest does not match the recorded value must be flagged as a potential integrity failure and investigated before the audit submission proceeds.

6.4 Consent Coverage Analysis

Consent coverage analysis verifies that every allow decision in the audit period is traceable to a valid, non-revoked consent state that was in effect at the evaluation timestamp. The analysis is performed by joining decision artifacts with consent state records on the consent reference and checking temporal validity.

The output of consent coverage analysis is a coverage report indicating, for each allow decision, whether a valid consent state reference exists, whether the consent was in scope for the declared purpose, and whether the consent was unrevoked at the evaluation timestamp. Decisions for which coverage cannot be confirmed must be investigated and documented in the audit trail.

Consent coverage analysis is a verification procedure, not an enforcement mechanism. Its purpose is to surface gaps in the evidence record that may indicate upstream consent capture or consent store issues. It does not retroactively alter decision outcomes.

#Evidence Pack Structure

A QODIQA evidence pack is a structured, self-contained collection of evidence materials organized for presentation to a regulator, auditor, or institutional counterparty. The pack must be complete, internally consistent, and accompanied by an index that maps each item to the regulatory obligation or audit objective it satisfies.

7.1 Required Documents

Every evidence pack must include the following mandatory documents. Additional documents may be included at the discretion of the submitting organization, but the mandatory set is the minimum required for a submission to be considered complete.

7.2 Artifact Inventory

The evidence pack must include a machine-readable artifact inventory that lists every decision artifact in the export with its identifier, timestamp, outcome, and policy version. The inventory enables auditors to confirm that the export is complete and to locate specific decisions for verification.

ArtifactInventoryEntry = {
    "decision_id":    str,
    "timestamp_utc":  str,   # ISO 8601
    "outcome":        str,
    "actor_id":       str,
    "purpose":        str,
    "policy_version": str
}

The inventory must be signed with a digest computed over the complete set of decision identifiers in the export, enabling verification that no entries have been added, removed, or modified after the inventory was generated.

7.3 Submission Format

Evidence packs must be submitted in a format that preserves the integrity of all included artifacts and enables independent verification without proprietary tooling. The canonical submission format is a structured archive containing JSON-encoded artifacts, human-readable index documents, and a top-level manifest that identifies the archive contents and their cryptographic digests.

Where a regulator or auditor specifies an alternative submission format, the organization must confirm that the alternative format preserves the structural completeness and integrity properties required by this document before adopting it. Conversion to an alternative format must not result in loss of any mandatory fields or integrity references.

#Operational Readiness

Operational readiness for audit is a continuous state maintained through normal system operation, not a preparation effort triggered by an impending audit. The following sections address the operational practices that sustain continuous audit readiness and the specific handling requirements for incidents and denial records.

8.1 Continuous Readiness Practices

Continuous audit readiness requires that the evidence generation, retention, and integrity verification procedures described in this document are embedded in operational workflows rather than treated as exceptional audit-time activities.

Organizations should maintain a running audit readiness dashboard that tracks the completeness of the four evidence categories, the currency of integrity verification, the sample coverage of replay verification, and the remaining time before the earliest evidence retention deadline. Any shortfall against these metrics should trigger an operational response before it becomes an audit finding.

Periodic internal audit exercises, in which a simulated evidence pack is assembled for a historical period and subjected to the verification procedures in Section 6, provide confidence that the full end-to-end audit process functions correctly before it is required in a regulatory context.

8.2 Incident Evidence Handling

When an incident occurs that may be subject to regulatory investigation, the evidence materials relevant to the incident period must be preserved with additional protections to prevent alteration or deletion. This may require creating a preserved snapshot of the audit trail segment corresponding to the incident period before any operational changes are made to systems that generated the relevant decisions.

The incident evidence record should include the preserved snapshot, a chronological summary of decisions made during the incident period, denial records if the incident involved enforcement failures or attempted bypasses, and any integrity verification records covering the incident period.

8.3 Denial Record Preservation

Denial records are among the most operationally significant evidence materials in a QODIQA deployment. They demonstrate that the enforcement layer was active and functioning correctly, and they provide evidence that consent violations or policy mismatches were detected and blocked rather than silently permitted.

Denial records must be preserved with the same completeness and integrity as allow records. They must include the full decision artifact, including the frozen evaluation context that shows which consent or policy condition caused the denial. In regulated contexts, denial records may be requested by regulators as evidence of effective consent enforcement, independent of whether any incident occurred.

The preservation of denial records is not merely a compliance obligation; it is a demonstration of the value of the enforcement layer. An organization that cannot produce denial records cannot demonstrate that its consent enforcement was active during any given period.

#Limitations and Scope

The evidence architecture and procedures described in this document are subject to constraints that arise from the deliberate design boundaries of the QODIQA framework. These constraints are not temporary gaps; they are structural choices that preserve the determinism and defensibility of the system.

9.1 Evidence Does Not Substitute for Legal Analysis

The regulatory compliance mappings in Section 4 are structural correspondences, not legal opinions. Organizations must conduct their own legal analysis to confirm that QODIQA evidence satisfies the specific requirements of applicable instruments in their jurisdiction and sector. The evidence pack structure defined in this document is a starting point, not a substitute for legal advice.

9.2 Upstream Consent Capture Is Out of Scope

QODIQA enforces consent at the execution layer; it does not capture consent from data subjects. The validity of the consent captured upstream and stored in the consent store is a separate concern that falls outside the scope of this document. Evidence of upstream consent capture mechanisms must be maintained separately and cross-referenced in the evidence pack where relevant.

9.3 Content and Semantic Evidence Is Not Produced

QODIQA does not inspect data content or produce evidence relating to the substance of data processed by AI systems. Evidence of data minimization, content appropriateness, or model behavior must be produced by other components of the AI governance stack and included in the evidence pack as supplementary materials where regulatory requirements demand it.

9.4 Evidence Covers Enforcement, Not Outcome

The evidence produced by QODIQA demonstrates that enforcement was correctly applied at the execution layer. It does not constitute evidence that the AI system's output was appropriate, accurate, or free from harm. Outcome-level governance evidence remains the responsibility of model governance and operational monitoring systems operating downstream of QODIQA.

#Conclusion

The shift from documentation-centric compliance to execution-layer enforcement changes the nature of audit evidence. In conventional governance models, an audit reconstructs what happened from logs, records, and testimony. In a QODIQA deployment, an audit verifies what happened against stable, cryptographically identified artifacts that were produced at the moment of execution and have not changed since.

This distinction is not cosmetic. It changes the burden of proof from plausibility to reproducibility. An organization that can replay any past decision and obtain an identical result, trace that result to an immutable policy version and a time-bounded consent state, and present this evidence in a structured, integrity-protected pack is in a fundamentally different position from one that can only offer logs and assertions.

The audit readiness and evidence architecture described in this document is a consequence of the QODIQA design rather than an addition to it. Organizations that deploy QODIQA correctly, and maintain the operational practices described here, are continuously audit-ready. Evidence packs are assembled from materials that already exist, verified by procedures that are already embedded in operational workflows, and submitted in formats that preserve the structural properties that make them verifiable.

As regulatory scrutiny of AI systems intensifies, the ability to demonstrate authorized, purposeful, and temporally bounded AI execution will become a baseline expectation. QODIQA provides the infrastructure through which that demonstration moves from aspiration to proof.

#Document Status and Corpus Alignment