VAP Specification v1.2

VAP is a cross-domain upper-level framework defining the structural requirements for cryptographically verifiable decision provenance in high-risk AI systems. Its scope is explicit: domains where system failure can cause irreversible harm to human life, societal infrastructure, or democratic institutions — finance, healthcare, transportation, energy, and public policy as mandatory application domains, with content/creative AI and capture provenance as profile-served domains.

The full text is maintained on GitHub; this page summarizes the load-bearing constructs. It is a summary, not the normative text.

What v1.2 changed

Version 1.2 is a framework-compatible / certification-stricter revision: all v1.1-conformant event data remains valid (event-data-compatible at the wire level; zero wire-format breaking changes). It (a) abstracts “Hash Chain MUST” into Cryptographic Sequence Verifiability MUST, (b) elevates external anchoring to a MUST at all conformance levels, and (c) promotes profile-proven capabilities — completeness guarantees, policy identification, ERASURE (crypto-shredding) events, bounded RECOVERY operations, cross-party provenance (XREF), and SCITT/COSE interoperability — into the Shared Assurance Core. Rationale and migration plan: VSO-VAP-CHANGE-001.

Core invariants (selection)

Fig. — Tamper-evidence, not tamper-proofing: altering e₂ after the fact does not stop anything, but the e₂→e₃ PrevHash check fails for any later verifier.

ID	Requirement
`INT-006`	Merkle batching and external anchoring of signed roots at all conformance levels; lightweight anchor targets (e.g., public RFC 3161 time-stamping) explicitly acceptable at the lowest levels.
`INT-007`	A documented anchor continuity plan: fallback anchor target, failover procedure with a bounded migration window, and retained AnchorRecords sufficient to verify historical anchors.
`INT-008`	Completeness Invariant. A third party must be able to verify, for any anchored batch, that no events within the batch’s declared scope were omitted after anchoring (omission / split-view detection). Each AnchorRecord binds event count, first/last event identifiers, and the governing policy identifier.
`INT-009`	Recovery operations that alter the effective sequence must be bounded, recorded, and authorized — and are never filtered from anchor batches.

Completeness scope note (normative): completeness is guaranteed at anchor time and at batch granularity. Profiles must state the completeness window implied by their anchoring frequency and require disclosure of this limitation when evidence is presented to authorities.

Missing data: the three tiers

Fig. — The three-tier taxonomy of missing data. Only Tier 3 is detectable after the fact; Tier 1 lies beyond the pre-measurement boundary by design.

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

Tamper-evidence answers “were these records altered?”; the Completeness Invariant answers “are these all the records?”. Both are required for evidentiary credibility — and Tier 1 remains, deliberately, out of reach. Events never measured are unrecoverable by design.

Fig. — Completeness Invariant (INT-008): the anchor binds count and first/last IDs, so a presented set with e₃ removed fails verification — at anchor granularity, against the declared scope.

Evidence Pack

A portable, self-verifying bundle for offline third-party verification: events, Merkle proofs, AnchorRecords, external anchor tokens, and key material references — verifiable without access to the system that produced them.

Versioning and change control

Version numbers identify documents; SHA-256 digests fix exact meaning. Approvals attach to digests, not version labels. Pre-release review findings fold directly into drafts with disposition records; approved documents are left untouched, and conflicts are resolved by precedence rules in the specification. Change control: VSO-VAP-CHANGE-001 (normative annex).

§1.6 Legal Scope and Non-Guarantee Statement (Normative)

“VAP and its domain profiles define mechanisms for producing cryptographically verifiable evidence of AI system decisions. Conformance to VAP or any profile: (a) does not constitute compliance with the EU AI Act, GDPR, MiFID II/III, CAT Rule 613, NIS2, FDA SaMD guidance, or any other law or regulation; (b) does not constitute a legal determination that any technical mechanism (including crypto-shredding) satisfies a specific legal obligation; (c) 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 (profiles SHOULD adopt this statement verbatim)

Acknowledged gaps

Stated in the specification and tracked openly: there is not yet a standardized vocabulary for decision-authority allocation; only the policy identifier is anchored, not the policy document text itself (no cryptographic binding of policy text yet); and the observation boundary imposes hard limits that no future revision can soften — see Tier 1 above.

IETF Internet-Drafts

draft-kamimura-vap-framework-01 — The VAP framework event and anchoring model
draft-kamimura-scitt-vcp-03 — VCP alignment with the SCITT architecture
draft-kamimura-scitt-refusal-events-03 — Refusal / denial events in transparency services
draft-kamimura-rats-behavioral-evidence-02 — Behavioral evidence in the RATS architecture
draft-vso-cpp-core-03 — CPP core (capture provenance)