VAP · veritaschain.org

Home / Blog / The Records That Were Never Created

Blog · 2026-08-19

The Records That Were Never Created

Oversight regimes for AI systems keep converging on the same two demands: keep logs, and keep humans in the loop. Both demands share a quiet assumption — that when someone later asks whether the obligation was met, the records will be there to answer. That assumption is the gap VAP was built around.

Altered versus absent

Most integrity technology answers one question: were these records altered? Signatures, WORM storage, and append-only logs are good at it. But an auditor, litigant, or regulator usually needs a second question answered first: are these all the records? A system that quietly never wrote the inconvenient event will pass every signature check you run, because every record it shows you is genuine.

Absence is harder than alteration because absence leaves nothing to inspect. Any framework that claims otherwise is overselling. So the honest move is to divide the problem into the part that is solvable, the part that is boundable, and the part that is permanently out of reach — and to say which is which in advance.

Three tiers of missing data

Three-tier missing-data taxonomy (VAP family)
TierConditionStatus under VAP
Tier 1The event was never measured — nothing crossed the observation boundaryPermanently unrecoverable by design. VAP is silent; no mechanism reconstructs it, and no deployment may represent otherwise
Tier 2Measured, but the record was lost before anchoringBounded and disclosed — the gap itself is recorded as an anchor-gap event with its bounds
Tier 3Anchored, then omitted from what is presentedThird-party detectable via the Completeness Invariant (INT-008): omission / split-view detection

Tier 1 is a hard boundary. An event that never crossed the observation boundary is unrecoverable by design; no mechanism in VAP reconstructs it, and no deployment may represent otherwise. What a framework can do is force the boundary to be declared — a ScopeManifest states up front what is being measured — so that “we never measured that” becomes a checkable claim about a declared scope rather than a convenient discovery after the fact.

Tier 2 is boundable. If a record existed and was lost before anchoring, the gap itself is recorded, with bounds. The window of possible loss shrinks to the anchoring interval, and that window is disclosed whenever evidence is presented.

Tier 3 is detectable. This is the Completeness Invariant, INT-008: every AnchorRecord binds the batch’s event count, first and last event identifiers, and the policy under which it was produced. Any verifier holding the anchor can detect post-anchor omission or a split-view presentation — showing one set of records to one party and another set to another.

Recording “no” as carefully as “yes”

Production systems are biased toward logging successes. Denials, refusals, and overridden recommendations are exactly the events later disputes turn on, and exactly the ones most likely to be missing. VAP’s denial-symmetry requirement treats negative decisions as first-class events: a refusal is chained, anchored, and attributable like any approval.

What VAP would not have done

VAP is post-hoc forensic and evidentiary infrastructure. It does not prevent, block, or intercept anything at runtime; it is tamper-evident, not tamper-proof; and per the specification’s own non-guarantee statement, conformance “does not warrant the correctness, fairness, or safety of the underlying AI decisions — only the integrity, completeness (at anchor granularity), and attributability of their records. VAP generates evidence; competent authorities and courts evaluate it.” (VAP v1.2, §1.6).

Where this project actually stands

Mandatory disclosure, as in every VSO document: zero external implementations, zero paying customers, zero Evidence Packs accepted in any proceeding. What exists today is a specification family (VAP v1.2, six domain profiles, two cross-cutting capabilities), five active IETF Internet-Drafts, and first-party reference code. The next milestone that matters is an external implementation — if you are considering one, start with the specification summary, the code examples, and standards@veritaschain.org.