The manifest contract
corpus names the newest release the corpus covers, not the only one: default_schema stays 1.0.1, so an entry that names no schema is still a statement about 1.0.1 and the existing fixtures are untouched. manifest_version went to 1.1 because the three options below are not decoration — a reader that ignores lineage_peers runs the VER1604 fixture with nothing to walk and gets a different answer from the one the manifest states.
Two different things are called profile, and the collision is worth naming. The header field is the conformance profile identifier a report carries, and a 1.1-draft run reports vera-profile/1.1-draft regardless of what the header says — the header states the default for the corpus, which is default_schema's profile. The per-entry profile option below is the strictness profile passed to the validator: default or high-trust. They are unrelated axes: high-trust is a way of reading the 1.1 draft's rules, not a fourth release.
A valid entry:
| field | meaning |
|---|---|
file | path relative to conformance/ |
description | what the fixture demonstrates |
allowed_warnings | codes that MAY be emitted. Any other code — of any severity — is a failure, and ok MUST be true |
An invalid entry:
| field | meaning |
|---|---|
file | path relative to conformance/ |
target_code | the code this fixture exists to exercise; the filename starts with it |
description | the seeded defect, in the standard's own terms |
expect_codes | the exact set of codes the validator must emit — not a subset |
expect_severity | error (⇒ ok false), warning (⇒ ok true), or none (no issues at all) |
Optional on either kind:
| field | meaning |
|---|---|
schema | 1.0.0, 1.0.1 or 1.1-draft. 1.1-draft selects the draft schema and the profile rules gated on it |
level | forces the effective conformance level |
max_bytes | the --max-bytes hard cap |
spaces_registry | path to a space registry of embedding space descriptors (--spaces, VER402) |
signature_key | path to a PEM public key (--signature-key, stage 15) |
registry | path to a VER Registry snapshot of governed value-space tokens (--registry, VER1205/VER1206) |
lineage_peers | list of paths to peer records the cycle search may walk (--lineage-peer, VER1604) |
profile | default or high-trust (--profile); high-trust promotes VER1606 to an error |
notes | operator-facing caveats: required flags, unavoidable collateral codes, how a digest was constructed |
Every path is relative to conformance/. spaces_registry and registry are deliberately two keys read by two loaders: they name different documents, and one key that accepted either file would find nothing in the wrong one and report it as a clean run.
also holds additional runs of the same file under different options. Each entry is merged over its parent, so it restates only what changes; null clears an inherited setting ("signature_key": null runs the fixture with no key). A valid entry's also may carry expect_codes, which then replaces allowed_warnings as the permitted set.
The corpus uses also for the claims worth pinning down rather than merely asserting in prose: that the two perceptual-digest fixtures emit their profile code alone under --schema 1.0.0, which is precisely the gap the 1.0.1 schema correction closes; that the signature fixtures behave differently with and without a key and never report an unverified signature as valid; that the three flag-gated fixtures are conformant when their flag is absent, so the flag is what reaches the rule; and that ver1103-c2pa-state-inconsistent, audited at --level L1, is silent — the other half of annex E28's ruling, which tells a producer that could not validate a manifest to omit provenance.c2pa and not claim L3. A validator that rejected that record below L3 would punish the behaviour the annex demands.
The 1.1-draft fixtures add four more such claims: that a registry snapshot turns VER1206 into VER1205 or into silence depending on what it lists, and never the other way round; that a lineage cycle is reported only when the peer that closes it was supplied, and its absence is never read as proof there is none; and that --profile high-trust promotes exactly one code and changes nothing else about the record.