VATS™
Verifiable AI Training Specification

Every AI system in production today was trained on data. Almost none of them can prove it — not to regulators, not to users, not to courts, and not to the public. The training data, the preprocessing steps, the known limitations, and the honest gaps are either undisclosed, vaguely described in a blog post, or buried in an internal document that will never be audited.

VATS™ (Verifiable AI Training Specification) is an open framework for creating independently verifiable records describing AI training provenance, model lineage, declared limitations, and associated evidence — anchored to Bitcoin and published to Arweave.

This is not a certification body. There is no committee. There is no annual audit fee. VATS documents declared training provenance and associated evidence. It does not certify legality, regulatory compliance, model quality, or authorization. The declaration lives on Arweave. The cryptographic commitment lives on Bitcoin when broadcast. Both are designed to be permanent. Neither requires trusting ICPO X™ or anyone else.

1.1 The Model Card Problem

Model cards, introduced by Google in 2018 and now widely adopted, describe a model's intended use, training data, and limitations in a structured document. They are helpful. They are also mutable. A model card is a webpage. It can be edited. It can be deleted. It carries no timestamp that cannot be falsified. There is no way to prove a model card said something at a specific point in time.

1.2 The Regulatory Gap

The EU AI Act (Articles 10–12) requires high-risk AI systems to document training data, preprocessing steps, and known limitations, with documentation maintained and available for inspection. Following the Digital Omnibus amendments adopted in mid-2026, these high-risk obligations apply from December 2, 2027 for stand-alone Annex III systems and from August 2, 2028 for AI embedded in regulated products.

The deferral changes the deadline. It does not change the structure of the obligation — and it sharpens the evidentiary problem rather than relieving it. Documentation obligations are retrospective by nature: they ask what the training data was, how it was prepared, what limitations were known. Evidence of those facts must be created when the work happens. Records not created during 2026–2027 development become gaps that must be explained in 2027–2028 review. Regulatory deadlines move. Evidence windows don't.

The Act does not specify how documentation should be made tamper-evident or permanently verifiable. As a result, compliance documentation today typically means a PDF or a database entry — both of which can be altered after the fact.

1.3 The Copyright Problem

Multiple ongoing litigations — including Andersen v. Stability AI, Getty Images v. Stability AI, and NYT v. OpenAI — center on contested questions of whether specific works were included in training data, with both sides arguing substantially from inference about records that were not designed to be independently verifiable.

VATS provides a framework for creating contemporaneous, independently verifiable records that may reduce uncertainty regarding declared training provenance.

1.4 The Trust Problem

Current AI transparency depends on developer self-disclosure. Major AI developers publish what they choose to publish about their training data, and there is no cryptographic commitment binding any of those disclosures to a point in time.

As a general structural matter, any disclosure regime without commitment permits silent revision: a disclosure can be updated after the fact, and no external party can prove what it previously said. VATS removes this option for any developer who adopts it — a VATS declaration, once committed, cannot be silently rewritten. It can only be corrected through a linked record that preserves the original.

2.1 Core Components

A VATS declaration consists of five required components and several optional extensions:

2.2 COMMONS Dataset Anchoring

Every dataset used in registered training is hashed using SHA-256. Under the specification, the hash is published to Arweave in an evidence envelope and committed to Bitcoin mainnet via OP_RETURN upon authorized broadcast. The resulting COMMONS Anchor ID (e.g., COMMONS-003) is the globally unique, independently verifiable identifier for that dataset state at that point in time.

If the dataset changes — even by a single byte — the SHA-256 hash changes, and a new anchor is required. This makes silent dataset modification cryptographically detectable.

The underlying dataset remains in the custody of the declaring party by default. Hash-only commitment is the default treatment; full-content publication requires separate authorization and is excluded for protected data classes.

2.3 The Lineage Certificate

A Lineage Certificate binds a model's identity to its declared training history. It includes the model name, version, architecture, training date, all COMMONS Anchor IDs used, fine-tune chain (if applicable), and the honest gap declaration. The certificate payload is published to Arweave and hash-committed to Bitcoin at issuance.

Every subsequent registered fine-tune creates a child certificate that references the parent. The declared training lineage is therefore traversable from any point in the chain — forward or backward — without trusting any single party's continued cooperation.

2.4 The Honest Gap Declaration

The gap declaration is the component most AI companies resist. It requires explicit disclosure of:

The gap declaration is a commitment to honesty, anchored alongside the claims. A system whose gap declaration documented a limitation cannot later credibly claim the limitation was unknown — the declaration is part of the same permanent record as everything else.

2.5 Verification Protocol

Any party can verify a VATS record without access to the ICPO X™ API:

Verification confirms the commitment — that these bytes existed in this form no later than that block. It does not verify every factual statement inside the record; those remain declarations, permanently preserved as declarations.

The VATS specification was published to production on June 8, 2026 as COMMONS-VATS-001, authored by ICPOX-AI-001 (TekTon) and authorized by ICPOX-001 (Christopher H. Walling).

Record status, disclosed in the specification's own three-field format:

Snapshot hash: bdb90247c8ee9fa74ad867ef474a684f6b2e61c6fbf70311576c6393b95acf62

Subsequent registrations followed as independent records with their own status disclosures, beginning with the first external gap declaration on June 11, 2026.

This record establishes timestamped precedence for this specific specification document. It does not establish that no earlier idea, method, or related implementation existed, and no broader priority claim is made.

4.1 AI Governance Documentation

Many emerging AI governance frameworks require organizations to maintain documentation regarding training data, development processes, and known limitations.

VATS is designed to support documentation and evidence readiness by creating contemporaneous, independently verifiable records describing declared training provenance.

Organizations remain responsible for determining whether their documentation satisfies applicable legal or regulatory requirements.

4.2 Training-Data Disputes

A VATS-anchored Lineage Certificate is a cryptographically verifiable record of what was declared regarding training inputs, created at the time of the work.

Developers who maintain contemporaneous, tamper-evident documentation may be better positioned to explain and substantiate their declared training process than developers reconstructing those records after the fact. VATS makes no representation regarding legal outcomes.

4.3 ICPO X Governance Alignment

VATS is maintained under ICPO X's published governance principles: honesty of declaration, permanence of record, explicit disclosure of gaps, and correction through linked records rather than retroactive revision. Registered participants commit to the honest-posture standard — declaring what they can support and what they cannot.

5.1 For independent AI developers

The entry tier provides Dataset Anchor and Lineage Certificate issuance for a single model — the starting point for researchers, independent labs, and developers who want to establish declared provenance before their model reaches production scale.

5.2 For enterprise AI teams

The enterprise tier covers up to 10 models with API access for programmatic provenance queries — appropriate for teams shipping into regulated or procurement-heavy environments: financial services, healthcare, legal, government.

5.3 For organizations preparing regulatory evidence

The Regulatory Evidence Package supports documentation preparation for organizations implementing AI governance frameworks, including the EU AI Act where applicable. It produces the evidence record that counsel, auditors, and reviewers examine. It does not determine legal classification, replace legal advice or a conformity assessment, or guarantee regulatory outcomes.

The AI industry has lacked a credible, permanent, independently verifiable standard for training-data provenance since the first model shipped. That gap is not accidental — it reflects a structural preference for opacity that has served developers of all sizes at the expense of users, creators, and reviewers.

VATS is not a certification body that can be captured. It is not a regulatory framework that can be watered down. It is a cryptographic standard anchored to Bitcoin.

The protocol preserves the evidence.

The first record is published. The lineage is public. The standard is live.

VATS supports evidence readiness through independently verifiable provenance documentation.

Corrections extend the record; they do not rewrite it. v1.0 remains published.