Negative Proofs
Most evidence systems record what happened. AIEP also records what did not happen. When evidence is absent, contradictory, or insufficient to support a conclusion, AIEP generates a Negative Proof — a tamper-evident record of that absence — rather than producing an uncertain output and discarding the uncertainty.
This is not an edge case. Negative Proofs are a first-class artefact type in AIEP’s architecture, and they are often more significant than positive evidence.
The problem with silent uncertainty
A conventional AI system presented with insufficient evidence produces one of two outputs: a confident-sounding response based on general training data (hallucination risk), or a refusal (“I don’t know”). Neither is verifiable. Neither creates a record that an auditor, regulator, or downstream system can inspect.
When the system later needs to demonstrate that it behaved appropriately — that it did not use uncertain evidence as if it were certain — there is no record. The uncertainty was ephemeral.
AIEP’s Negative Proof architecture eliminates this. Uncertainty is recorded, signed, and persisted.
Structure of a Negative Proof
A Negative Proof artefact includes:
| Field | Content |
|---|---|
artefact_type | "negative_proof" |
query_hash | SHA-256 of the query that produced no sufficient evidence |
searched_sources | List of artefacts retrieved and assessed as insufficient |
assessment | Structured reason: absent, contradictory, out-of-scope, or stale |
timestamp | ISO 8601 timestamp at point of assessment |
session_genesis_ref | Hash reference linking this artefact to its session genesis record |
schema_version | Canonical schema version in force at production time |
The Negative Proof is hash-committed and written to the Evidence Ledger before any response is returned. It cannot be generated retroactively for a query that was processed without one.
When Negative Proofs are generated
Negative Proofs are generated automatically in four cases:
- Evidence absence — retrieval returns no artefacts matching the query context
- Contradiction — two or more artefacts with equal provenance weight present incompatible claims
- Staleness — retrieved artefacts are outside the freshness window defined by the deployment’s evidence policy
- Out-of-scope — the query falls outside the operator’s configured evidence domain and no authoritative source was retrieved
In cases 2 and 4, the Negative Proof includes references to the contradicting artefacts or the boundary definition that triggered it.
Why Negative Proofs matter for compliance
Under GDPR Article 22 and the EU AI Act’s transparency requirements, systems must be able to explain what evidence was used in an automated decision — and where evidence was absent or uncertain, that must be documented. A Negative Proof satisfies this requirement directly.
For high-risk AI systems operating under Article 13 (transparency) and Article 14 (human oversight), the ability to surface a machine-readable record of “this decision was based on insufficient evidence” is structurally more useful than a narrative disclaimer.
See EU AI Act Compliance and GDPR & AI Compliance for the regulatory context.
Relationship to Verifiable Records
Negative Proofs are a sub-type of AIEP’s Verifiable Record. They satisfy the same three properties:
- Integrity — hash-committed at production; cannot be modified after the fact
- Provenance — the sources that were assessed and found insufficient are listed by hash
- Replayability — the Replay Kernel can reconstruct the absence finding from the ledger record
See Verifiable Records for the full record architecture.
Related
→ Verifiable Records · Evidence Layer · EU AI Act Compliance · GDPR & AI Compliance · Spec