VER 1.0.1

Status: PUBLISHED. Artifact release 1.0.1 of the VER 1.0 standard. Released 23 August 2026. Supersedes nothing: it corrects, and 1.0.0 stays frozen and retrievable at standards/ver/1.0.0/.

What this release is

1.0.1 is a patch over the published artifact set — specification text, schema, and example — not a new record format. Records remain "ver_version": "1.0" and "cpnp_version": "1.0". A consumer written against 1.0.0 parses every 1.0.1 record without change.

The specification document is never edited in place. Corrections ship as VER-1.0.1-errata-annex.md, which is normative and governs where it and the 1.0.0 text disagree.

Reproduce the digests from the repository root:

.venv/bin/python -c "import hashlib,pathlib;[print(hashlib.sha256(p.read_bytes()).hexdigest(),p.name) for p in sorted(pathlib.Path('standards/ver/1.0.1').iterdir()) if p.name!='RELEASE.md']"

The 1.0.0 specification document (VER-1.0-Specification.docx) is not copied into this directory. There is exactly one published copy of it, at standards/ver/1.0.0/VER-1.0-Specification.docx, and this release annotates it rather than reissuing it.

Delta from 1.0.0

Schema — three constraint changes, plus $id, title, and one added sentence in description:

1. Perceptual digest length is bound to the algorithm (pdq/1.0 ⇒ 64 hex, phash-dct/64 ⇒ 16 hex) via if/then. The alg enum is unchanged.
2. identity.pixel_hash gains "additionalProperties": false.
3. identity.content_hash becomes {"allOf": [{"$ref": "#/$defs/sha256Hash"}], "unevaluatedProperties": false}.

$defs/sha256Hash is deliberately left open — closing it would break the pixel_hash allOf branch — so closure is applied at each use site instead.

Example — five corrections:

Edit (e) is new in this revision of the release and is the one that changes the example's conformance story. The 1.0.0 payload was an elision: 30 octets of a profile whose own header declared 3144, carrying no ICC_PROFILE\0 identifier prefix. That made the example non-conformant at its own declared conformance_level of L3, against annex item E11 (a preserved JPEG APP payload includes the identifier prefix and the sequence octets) and against E26 (no elided segment in a Record claiming L1 or above). The example now carries ICC_PROFILE\0 + the sequence octets 01 01 + a complete 588-octet sRGB ICC profile, and /metadata/raw/0/sha256 is the SHA-256 of exactly those 602 octets. The profile parses: its header's size field reads 588, its signature at offset 36 is acsp, and lcms re-opens it as an sRGB monitor profile. §2.2 of the annex carries the generation recipe and the reproduction command.

Rationale, defect analysis, and the finding identifiers behind each change are in §2 of the errata annex.

Compatibility

Schema direction.

• A 1.0.0-valid record fails the 1.0.1 schema only if it carries a perceptual digest of the wrong length for its algorithm, or an undeclared member inside identity.content_hash or identity.pixel_hash. All three already violated normative 1.0.0 prose, so no conformant record is invalidated. The frozen 1.0.0 example is itself such an instance: it fails the 1.0.1 schema on exactly one pointer, /identity/perceptual/0/value.
• The 1.0.1 example validates under both schemas. The golden example must never be the artifact that forces a consumer upgrade.
• No 1.0.1-valid record fails the 1.0.0 schema. Every schema change is a tightening.

Identity tier. CPNP-1's algorithm is unchanged and cpnp_version stays "1.0". But five annex items — E3, E6, E7, E8 and E9 — each resolve an ambiguity where two defensible readings of the 1.0.0 prose produced different Canonical Buffers for the same Asset, and resolving an ambiguity necessarily selects one reading. Records produced under a non-selected reading were never interoperable and are non-conformant under this annex; their pixel_hash values are withdrawn, not recomputed, because the two values were never values of the same function. No record produced under a selected reading changes. E8 additionally withdraws canonical identity entirely for an Asset carrying a present-but-unusable ICC profile. Annex §1 property 2 and §5.1's item index state this per item; COMPATIBILITY.md carries the row-by-row impact.

One relaxation. 1.0.1 is otherwise a tightening-or-disambiguation release, with a single deliberate exception recorded in annex item E15: §7.1's L1+ byte-exact-preservation MUST is made subordinate to §7.5 redaction. A redacting Producer that omits a sensitive segment from raw[] is conformant under 1.0.1 and was not conformant under a literal reading of 1.0.0 §7.1. This is the one direction in which 1.0.1 relaxes 1.0.0. Nothing becomes structurally invalid — the schema is unchanged in this area — but a consumer applying 1.0.0 §7.1 literally may judge such a record non-conformant. In-segment scrubbing is not an alternative remedy: a raw[] entry has no member that distinguishes acquired evidence from a producer-edited derivative, so a scrubbed segment would masquerade as byte-exact acquisition evidence. Scrubbed-segment carriage with an explicit marker is 1.1 ratification material.

Verification

Everything below runs from the repository root with the repository virtualenv and no installation step.

Schema validation

.venv/bin/python - <<'PY'
import json
from jsonschema import validators, FormatChecker
load = lambda p: json.load(open(p))
s100 = load("standards/ver/1.0.0/ver-record.schema.json")
s101 = load("standards/ver/1.0.1/ver-record.schema.json")
e100 = load("standards/ver/1.0.0/example-record.json")
e101 = load("standards/ver/1.0.1/example-record.json")
for name, s in (("1.0.0", s100), ("1.0.1", s101)):
    validators.validator_for(s).check_schema(s)
    print("check_schema", name, "OK")
def errors(schema, inst):
    cls = validators.validator_for(schema)
    return list(cls(schema, format_checker=FormatChecker()).iter_errors(inst))
print("1.0.1 example / 1.0.0 schema:", len(errors(s100, e101)), "errors")
print("1.0.1 example / 1.0.1 schema:", len(errors(s101, e101)), "errors")
for e in errors(s101, e100):
    print("1.0.0 example / 1.0.1 schema:", "/" + "/".join(map(str, e.absolute_path)), "|", e.message)
PY

Expected: 0, 0, and exactly one error at /identity/perceptual/0/value.

Conformance profile validation

PYTHONPATH=packages/ver-validator/src .venv/bin/python -m ver_validator.cli \
    standards/ver/1.0.1/example-record.json

Expected: ok, zero errors, and the single VER308 warning — an L3 record SHOULD carry provenance.signature, and this one does not, because a signature over illustrative data would itself be illustrative (annex E26).

If your environment's virtualenv has pip, pip install -e packages/ver-validator also puts a ver-validate console script on the path, and ver-validate standards/ver/1.0.1/example-record.json is then equivalent. That is the alternative, not the default: this repository's .venv has no pip, and the PYTHONPATH invocation above needs none.

A note on format

A stock jsonschema FormatChecker asserts uuid but not date-time or uri unless the optional rfc3339-validator and rfc3986-validator packages are installed. Errata item E23 requires a conformance validator to assert both, along with contentEncoding; the conformance profile validator in packages/ver-validator/ does so (VER202) and is the artifact that checks them.

Open decisions

One item in this release is unresolved and is tracked as an ADR rather than decided by fiat: whether metadata.redactions[].salted_sha256 is REQUIRED (ADR-0006, errata item E15). Both schemas leave it optional; the profile validator warns (VER1002).

Related artifacts