Evidence Assurance Profiles & Claim Discipline

Structured Trust Models for Verifiable Governance

Not all evidence carries the same weight. A screenshot of a dashboard, a mutable database row, a cryptographically signed receipt, and a Merkle-batched custody vault object represent fundamentally different levels of integrity and verifiability.

The AI Governance Evidence Infrastructure (AGEI) and Cognitive Insight Audit Framework (CIAF-LCM) establish a structured trust model to make proof strength explicit. This model prevents organizations from overclaiming their state of compliance, while providing engineering teams with a clear, multi-tier maturity roadmap.

1. Why Assurance Profiles Matter

When an organization asserts that an AI system is "governed," "compliant," or "safe," that claim is only as strong as the underlying evidence. By defining explicit Evidence Assurance Profiles, we:

  • Avoid "Governance Theater": Shift from narrative promises and manual checklists to objective, machine-verifiable facts.
  • Provide a Maturity Path: Enable organizations to adopt controls progressively, starting with simple logging and scaling to legal-grade forensic custody.
  • Establish Verification Discipline: Ensure that auditors, regulators, and verifiers understand the exact trust boundary of any given evidence package.

2. The Three Assurance Profiles

The framework defines three distinct levels of evidentiary strength. Each level introduces more stringent requirements for signing, storage, batching, and verification.

Profile 1: Internal Evidence (Lightweight Posture)

  • Primary Use Case: Internal operations, early-stage pilots, system debugging, and basic control visibility.
  • Verification Boundary: Suitable for internal teams who trust the underlying database and application environment. It does not provide strong defense against skeptical or adversarial external reviews.
  • Key Database Objects: policy_sets, policy_rules, gate_evaluations, receipts (without signatures), and evidence_objects.

Minimum Technical Expectations:

  • Policy Structure: Validated policy_sets and active policy_rules must exist and be queryable for all governed use cases.
  • Control Points: Immutable gate_evaluations are recorded at key lifecycle transitions (e.g., model promotion, deployment).
  • Receipts: Standard receipts are generated for each gate event, containing a standard content_hash, a defined hash_algorithm (SHA-256), and a canonicalization_version (JCS / ciaf-json-v1).
  • Lineage: Cross-references exist in database rows to link dataset, model, and deployment stages.

Profile 2: Regulated Evidence (Compliance Readiness)

  • Primary Use Case: External audits, horizontal compliance certifications (e.g., EU AI Act Article 12, ISO/IEC 42001, NIST AI RMF), customer procurement assurance, and standard regulatory reporting.
  • Verification Boundary: Suitable for third-party examiners. The evidence stands on its own, proving that specific controls ran at specific times under specific policy versions, authenticated by key-backed digital signatures.
  • Key Database Objects: All Profile 1 objects, plus audit_packs, audit_pack_items, and verification_jobs with explicit cryptographic signature fields.

Minimum Technical Expectations:

  • Immutable Policy Linkage: Every receipt is hard-linked to an immutable policy_version_id and gate_evaluation_id.
  • Cryptographic Signatures: Every receipt carries an active signature (such as Ed25519 or classical fallback), a signature_algorithm field, signed_by key identifiers, and a secure NTP-synchronized signed_at timestamp.
  • Deterministic Audit Packs: When an audit is triggered, audit_packs and audit_pack_items freeze and snapshot the target receipts, policy versions, and evidence payloads. This ensures subsequent database state changes do not alter historical audit responses.
  • Verification Pipeline: Examiners can run offline verification_jobs that re-canonicalize, re-hash, and verify signature paths over exported audit packs without requiring direct database access.

Profile 3: Forensic Evidence (Dispute & Legal-Ready)

  • Primary Use Case: Adversarial reviews, legal disputes, contract breaches, post-incident investigations, high-dollar transactions, and strict chain-of-custody scrutiny.
  • Verification Boundary: Designed to withstand hostile cross-examination and skeptical external verifiers. It guarantees that evidence has not been backdated, re-ordered, deleted, or altered, even by database administrators.
  • Key Database Objects: All Profile 2 objects, plus vault_objects, receipt_batches, receipt_batch_items, personal_data_references, privacy_redaction_events, and legal_holds.

Minimum Technical Expectations:

  • Sealed Custody: Select receipts and evidence objects are serialized, hashed, and sealed inside immutable vault_objects configured with write-once, read-many (WORM) retention periods (retention_until).
  • Merkle Tree Batching: Receipts are grouped into Merkle trees via receipt_batches and receipt_batch_items. The batch preserves a merkle_root that is anchored to an external notarization ledger. This supports highly efficient membership proofs, allowing verifiers to confirm a single receipt's existence without exposing neighboring data.
  • Zero-Trust Verification: Verification jobs validate signatures, hashes, Merkle paths, and chain-of-custody consistency across the entire ledger.
  • Privacy-Safe Evidence (GDPR Compliance): Personal data is kept outside the receipts and vault. Instead, the vault stores personal_data_references and logs cryptographically signed privacy_redaction_events. This allows organizations to fulfill Data Subject Erasure requests without breaking the mathematical continuity of the audit trail.
  • Legal Holds: Support for legal_holds that suspend automated deletion workflows for defined scopes during active inquiries.

3. Claim Discipline: A Vocabulary for Truth

A core failure in modern compliance programs is overclaiming. Organizations frequently use absolute terms that are technically unsupportable, creating legal and operational liability.

To maintain strict integrity, any system deploying the Cognitive Insight Audit Framework must enforce the following Claim Discipline Vocabulary during audits and public reports:

❌ What NOT to Say (The Overclaim)✅ Better / Proper ClaimTechnical Justification
"This proves compliance.""This provides verifiable evidence supporting the stated control execution."Compliance is a continuous legal and operational state; the framework proves only that defined policies evaluated and gates executed.
"This proves the model was safe.""This proves the model passed the specified validation gate under the referenced policy version.""Safety" is an open-ended, contextual attribute; a receipt proves only that the system satisfied the mathematical and human thresholds defined in a versioned policy file.
"The artifact is authentic.""The artifact matches, or probably links to, the referenced release record under the stated verification method."Downstream files may be cropped, transformed, or excerpted; provenance claims must define whether they matched via exact post-watermark hash, pre-watermark hash lineage, or probabilistic forensic fingerprint thresholds.
"The vault is immutable forever.""The vault provides tamper-evident custody under defined retention, legal hold, and deletion policies."Blanket immutability is a myth that conflicts with legal erasure obligations (GDPR); the vault provides verifiable tamper-detection combined with controlled deletion lifecycles.
"The agent acts independently.""The agent acts under defined delegated authority on behalf of a delegating principal."AI agents do not have legal standing; they operate as technical extensions of authorized human or system principals, bounded by explicit delegation tokens.

4. The 4-Step Maturity Roadmap

Organizations do not need to implement Profile 3 on day one. We advocate for a progressive Adoption Maturity Roadmap:

5. Relational Schema Mapping

In your relational database schema, these assurance dynamics are directly controlled by tracking fields across key tables:

  • receipts.merkle_proof & receipt_batch_items.merkle_proof: Represents batch membership under Profile 3. If null, the receipt is evaluated at a Profile 2 level.
  • receipts.signature & vault_objects.signature: Stores the Ed25519 cryptographic signature. Under Profile 1, this column remains blank or holds an internal HMAC-based verification code.
  • policy_versions.canonicalization_version & gate_evaluations.canonicalization_version: Ensures JCS/ciaf-json-v1 normalization is declared, enabling offline verify jobs to match hashes.
  • vault_objects.retention_until: Enforces custody-grade WORM constraints for Profile 3.