A record either reproduces the manifest, or it disagrees with the standard
Four levels in the specification, eighty-three issue codes in the profile, and one fixture per code so the profile can be run rather than read.
The four levels
M = mandatory, S = SHOULD, — = not required.
Pixels only
CPNP-1, both identity hashes, and at least one canonical visual embedding with a full space descriptor. Nothing else is required.
Raw metadata preserved
Every metadata family preserved byte-exact, with an availability state recorded for each.
Reconciled and trusted
A reconciled normalized view with precedence and conflicts, trust tiers, and redaction-with-proof.
Provenance and context
Acquisition and custody chain, C2PA validation, contextual embeddings with source provenance, and a record signature.
| Capability | L0 | L1 | L2 | L3 |
|---|---|---|---|---|
| CPNP-1, content_hash, pixel_hash | M | M | M | M |
| ≥ 1 canonical_visual embedding + full space descriptor | M | M | M | M |
| Byte-exact raw metadata preservation | — | M | M | M |
| Availability states per family | — | M | M | M |
| Reconciled view, precedence, conflicts[] | — | — | M | M |
| Trust tiers; redaction-with-proof | — | — | M | M |
| Acquisition + chain; C2PA validation | — | — | — | M |
| Contextual embeddings w/ source provenance | — | — | — | M |
| Record signature (JWS/COSE over JCS) | — | — | — | S |
Seventeen stages, run in order, none of them skipped
Every stage runs. The validator does not stop at the first error, because a producer fixing one defect deserves to see the rest.
| Stage | What it checks | Codes |
|---|---|---|
| 0 | The validator itself, not the record | VER001 |
| 1 | Parse and size | VER101VER102VER103VER104VER105VER106 |
| 2 | Structure and formats | VER201VER202 |
| 3 | Conformance level gates | VER301VER302VER303VER304VER305VER306VER307VER308 |
| 4 | Space descriptors | VER401VER402VER403VER404VER405VER406VER407VER408VER409VER410VER411 |
| 5 | Referential integrity | VER501 |
| 6 | Dimensions, dtypes and component values | VER601VER602VER603VER604VER605VER606VER607VER608VER609 |
| 7 | Role and kind agreement | VER701VER702VER703VER704VER705 |
| 8 | Perceptual digests | VER801VER802 |
| 9 | Availability completeness | folded into VER303 |
| 10 | Availability basis and raw-segment carriage | VER901VER902VER903VER904 |
| 11 | Trust, conflict, redaction | VER1001VER1002VER1003VER1004VER1005VER1006VER1007VER1008VER1009VER1010VER1011 |
| 12 | C2PA state | VER1101VER1102VER1103 |
| 13 | Provenance chronology and action tokens | VER1201VER1202VER1203VER1204VER1205VER1206VER1207VER1208 |
| 14 | Checksums | VER1301VER1302VER1305 |
| 15 | Signature | VER1401VER1402VER1403 |
| 16 | Lineage | VER1601VER1602VER1603VER1604VER1605VER1606 |
One code, one fixture, one expected verdict
Every issue code has exactly one fixture registered against it, or an explicit exemption saying why it cannot have one. A code with neither, or two fixtures claiming the same code, is a corpus defect.
Manifest 1.1, corpus ver-conformance/1.1-draft, generated 2026-08-25. The default schema for a run is 1.0.1.
Conformance documents
Three documents describe what a validator does, how it says it, and what holds it honest.
High-trust conformance profile
vera-profile-high-trust/1.1-draft — one severity promotion over the base draft profile.
The conformance validator
ver-validator: what each of the seventeen stages checks, the JSON report contract, and the Python API.
The fixture corpus
Ninety-five executable fixtures: one per issue code, with the expected verdict recorded in a manifest.
