Validate the claim, layer by layer

A sequence of distinct checks#

The normative specification and profiles define the contract; JSON Schema handles only part of it. A reference implementation is valuable evidence of behavior but does not replace the normative documents. Similarly, a generic JSON Schema validator must enable the required format assertions. Passing an easier structural check is not equivalent to completing the specified conformance process.

Start with mandatory profiles, then inspect capabilities#

Every VAO 0.5.0 object requires Core and Dynamic Delivery, even if its payload is embedded in a single carrier. Additional requirements depend on what the object represents. Scientific records, timebases, physical systems, playable behavior, spatial records and acoustic records bring their corresponding profile obligations. A declaration alone does not prove that the object satisfies the profile or that an application can execute it.

Materialization is a further distinction. A manifest can describe several groups while a local carrier contains only a subset. A consumer must acquire and verify the required groups before claiming a profile is materialized. A metadata-only inspection can succeed without making geometry, audio or an interactive runtime locally available. The validation report should make that state understandable.

Try the standard’s own fixture first#

python Tools/vao05.py validate Fixtures/VAO05/workspaces/minimal
python Tools/vao05.py validate-release \
  Fixtures/VAO05/companions/release.example.json \
  Fixtures/VAO05/workspaces/minimal/vao-manifest.json

These documented commands assume the standard’s release checkout as the working directory and its required Python environment. The first checks a supplied workspace fixture; the second checks the example release descriptor against the fixture manifest. They are a starting point for understanding the report. Replace the paths with your own artifacts only after confirming the tool version and the relevant object version.

Hash the artifact the specification identifies#

Exact manifest bytes are not interchangeable with reserialized JSON. Whitespace or property ordering can change the byte digest even if a parser produces an equivalent object. Other records may prescribe a canonicalization procedure, such as RFC 8785 for the applicable conformance trace. Identify the procedure for each digest. A website chapter fingerprint, a VAO manifest digest and a carrier archive digest serve different objects and must not be substituted for one another.

A consumer should verify downloaded bytes before exposing them as a verified realization. A validator can inspect a carrier without extracting it, and a failed acquisition should remain a failed attempt in the receipt. Successful validation of one carrier does not establish that all externally referenced assets are available. A preservation claim needs the stated closure, not just a readable bootstrap.

A useful report says what was not run#

Record the standard edition, validator version, input identity, requested checks, results and unperformed checks. Deterministic-runtime trace tests concern their defined offline subset; they do not by themselves demonstrate a complete real-time scheduler, audio engine or haptic system. Linked-data validation applies when that capability is claimed, with the JSON record remaining authoritative under the VAO contract. Finally, technical conformance does not decide whether an acoustic inference or historical attribution is scientifically justified.