VER 1.1

⚠ DRAFT — NOT RATIFIED — DO NOT PUBLISH RECORDS AGAINST THIS

Everything in this directory is a working draft dated 23 August 2026. No artifact here is published, stable, or citable as a standard. $id https://verstandard.org/schemas/ver-record-1.1-draft.json is a draft identifier and will be replaced by an immutable …/ver-record-1.1.json at ratification; the draft identifier will not be reused.

Producers MUST NOT emit "ver_version": "1.1" to third parties outside an agreed ratification trial. Consumers MUST NOT treat this schema as a conformance authority. Every numeric threshold in the draft is a proposal awaiting evidence.

The verdict, stated plainly

1.1 stays a draft until the blocking deliverables below exist.

The 23 August owner review took five architecture decisions — ADR-0004 through ADR-0008 are now Accepted, three of them with revisions that are in this directory's artifacts, and ADR-0006's closure leaves the VER standards track with no open decisions. That is genuine progress and it is not ratification. Decisions taken are the cheap half. What ratification requires is the other half. Six of the seven rows below now have an artifact behind them where none did on 23 August: two are discharged, four carry a stated remainder, and the seventh has not started.

Publishing a standard whose deliverables do not exist is how 1.0 acquired the 189-finding audit this branch is answering. VERSIONING.md §3.4 now states the publication bar in general terms; this section is that bar applied to 1.1.

Contents

The profile validator in packages/ver-validator/ now carries a 1.1-draft profile beside the 1.0 one (--schema 1.0.0 | 1.0.1 | 1.1-draft, reporting itself as vera-profile/1.1-draft), so the artifacts in this directory can be checked with it — checklist row 12. The verification section below stays a bare schema check, because it must run without installing anything:

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

is the no-install invocation; pip install -e packages/ver-validator plus ver-validate is the alternative for environments whose virtualenv has pip (this repository's .venv does not).

Compatibility posture

VER 1.1 adds capability. CPNP-1 is unchanged and cpnp_version stays "1.0", so a 1.1 Record's pixel_hash lives in the same universe as a 1.0 Record's, and nothing on this branch moves a pixel_hash.

Moving a Record from 1.0.1 to 1.1 is a real migration. An earlier revision of this draft advertised the 1.1 schema as a superset of the 1.0.1 schema — ver_version and dim/dtype and "nothing else". That property was real, and it was bought by leaving encodable rules out of the schema: the binary-space constraints, the multi-segment index requirement, the tolerance floor, the URI/digest couplings, and seven objects that the prose closes and the schema did not. The owner review deprioritised the superset goal, and the trade is now made the other way: every rule JSON Schema can express is expressed, and the migration is enumerated instead of avoided.

Draft §12.1 is that enumeration — fourteen rows, each with the failure pointer a validator emits when the edit is not made. It is empirical, not asserted: the "Verification" section below carries the command that produces it, and the numbers in §12.1 are that command's output against this repository's own artifacts.

The short version, measured:

• the 1.0.1 golden example fails the 1.1 schema on three pointers — /ver_version, /spaces/0/reference, /spaces/1/reference;
• across the ten 1.0.1 conformance/valid/ fixtures, those same two edits (declare 1.1, add set_manifest_sha256) account for every failure in eight of them. Two fixtures reach three further rows between them: binary-dtype.json (a binary space declaring metric: "cosine" and a cosine tolerance) and redacted-with-proof.json (salted_sha256 in the ledger and in the normalized view). **Five of §12.1's fourteen rows are reached by that corpus; nine are reached by nothing in it**, which is why 1.1 needed fixtures of its own — row 11 below, now discharged.

Rules that remain outside the schema are listed in draft §15.4 and are there for one of two reasons, each stated per rule: JSON Schema cannot express them at any price (uniqueness, cross-member arithmetic, digest recomputation, graph acyclicity, domain ownership), or they are deliberately profile-graded with the reason given (the size limits, per-kind preprocessing completeness, the redacted-value shape below the top level of the normalized view). The "not encoded to preserve compatibility" bucket is empty.

How the example's digests were produced

Every hash in example-record-lineage.json is a real digest of bytes that were actually constructed, not a placeholder. The construction is deterministic and reproducible:

• Assets. Two 64×48 PNG parents are generated from closed-form pixel functions — parent A: (R,G,B) = ((4x)%256, (5y)%256, (3(x+y))%256); parent B: ((7y)%256, (3x)%256, (xy+17)%256) — and the 128×48 composite places A at x=0 and B at x=64. content_hash is the SHA-256 of the encoded PNG file bytes (Pillow, compress_level=9); image.source_bytes_ref.byte_length is that file's real length.
• pixel_hash. Computed with the 1.0 §4 preimage over the real decoded buffer: `SHA-256(UTF-8("VER1:" + width + ":" + height + ":sRGB8:") + raw_bytes),raw_bytesbeing exactlywidth · height · 3` interleaved RGB octets. The parents' pixel_hash values in lineage.parents[] are computed the same way over the parent buffers.
• phash-dct/64. A genuine 64-bit DCT perceptual hash of the Canonical Buffer, computed with imagehash 4.3.2 per errata item E22. No pdq/1.0 digest is carried, because this draft pins no PDQ implementation and a fabricated one would be worse than none.
• Vectors. v[i] = sin(i + 1 + phase), L2-normalized, packed little-endian float32 (phase = 0 for the canonical visual vector, 1.5 for the contextual one); the binary vector is `bit i = 1 iff sin(i+1+0.25) > 0`, packed 8 bits per octet MSB-first. Byte lengths therefore satisfy dim × 4 (3072) and ceil(dim/8) (32) exactly, and the contextual vector_ref.sha256 is the digest of its 3072 real octets.
• bundle.manifest_sha256. SHA-256 of the RFC 8785 JCS serialization of {"files": [...]} over the bundle's files sorted by path — the ver-bundle-manifest/1 construction, computed rather than asserted. **The two spaces derive different values**, and that is the point of draft §4.2's rule that a bundle lists the files affecting the forward pass the space declares: the joint_visual_text space lists config.json, model.safetensors and tokenizer.json; the image-only binary space over the same checkpoint lists the first two and MUST NOT list the tokenizer, which cannot affect an image embedding. Its PCA basis, which does affect its output, is pinned in model.artifacts[] with role: "pca_basis", because it is not a file of the checkpoint.
• weights_sha256. The digest of model.safetensors alone — a producer's documented choice under annex E29's reading, identical for the two spaces because they load the same weight file. It is deliberately not the bundle digest: draft §4.2 keeps weights_sha256 producer-scoped and puts the cross-producer pin in manifest_sha256, and the example shows the two side by side so the difference is visible rather than described.
• descriptor_sha256. SHA-256 of the JCS serialization of each space descriptor with its own descriptor_sha256 member removed.
• set_manifest_sha256. SHA-256 of the JCS serialization of a real reference-set manifest per space: `{"reference_set_version": "1", "space_id": …, "items": [{name, content_sha256, pixel_sha256, vector_sha256} × 3]}`, whose three items are the two parents and the composite with their true content_hash and pixel_hash values and the digest of a vector generated by the same closed form as above. The manifest documents themselves are illustrative (E26) — they are not published anywhere — but the digests are of bytes that exist.
• recipe_sha256. SHA-256 of the JCS serialization of the recipe envelope of draft §3.4, which is exactly:

  {"recipe_version":"1","canonicalization":"rfc8785-jcs",
   "steps":[{"op":"canvas","width":128,"height":48,"background":"#000000"},
            {"op":"place","source":"parent-a","x":0,"y":0},
            {"op":"place","source":"parent-b","x":64,"y":0}],
   "x-org.example.studio":{"template":"diptych-128x48"}}

The same value appears as the compose chain event's params_sha256 and inside recipe_uri, so the three are cross-checkable.

• params_sha256 on the normalize event. SHA-256 of the JCS serialization of `{"black_point_compensation": false, "cmm": "lcms2", "cpnp_version": "1.0", "intent": "relative_colorimetric"}`. It is a real digest of a real parameter document, not a placeholder — this is the member the 1.0.0 example filled with an arbitrary string.
• Raw segments. The two XMP packets and the C2PA payload are real byte strings and their sha256 values are the digests of the decoded octets (errata E11). The XMP family occupies two segments, so both carry index — which is what makes the example exercise §10.1's newly-encoded rule. The ICC segment is carried by reference; its 3144-octet blob declares its own true length in its first four octets — deliberately, so this example never repeats the 1.0.0 example's self-contradicting truncated profile (errata E26) — and is built as uint32be(3144) ‖ "VER-ILLUSTRATIVE-ICC-PROFILE-BODY-" padded to 3144 octets with byte[i] = (i·37 + 11) mod 256.
• commitment_sha256. The draft §5.3 construction, computed:

  SHA-256( "VER-REDACTION-COMMITMENT-1"
         ‖ uint64be(len(salt))       ‖ salt
         ‖ uint64be(len(JCS(value))) ‖ JCS(value) )

with value = "51.4779N" — the GPS latitude as it appeared in the normalized view, so JCS(value) is the ten octets "51.4779N" including the quotes — and a 32-octet salt whose hex is 5f2b9d4c7a10e836c1d94f0b2e7a6538bd41c09e72a5f3861d0b4e97ca25f8d3. The salt is published here and only here. It is in this file so the digest is reproducible; it is correctly absent from the Record, which is the entire mechanism. A real deployment's salt is never written down anywhere a reader of the Record can reach.

Two things the example deliberately does not carry. There is no sign chain event, because the example carries no provenance.signature and the 1.1 schema now forbids the one without the other (§2.3.3) — fabricating a signature value to demonstrate a rule about signatures would be the exact defect class this revision exists to remove. And there is no provenance.registry, because every action in the chain is one of the sixteen the specification itself defines, so no registry snapshot is depended on. Both rules are negative and belong in conformance fixtures, which is where they now are — invalid/ver1207-… and invalid/ver1205-…, checklist row 11.

Still illustrative, and marked as such by errata item E26: the URIs, the model checkpoint identity, the reference-set identifiers, the PCA basis, and the C2PA manifest content. They are not retrievable and no conformance claim may rest on them.

Verification

From the repository root.

1 — the schema is a legal 2020-12 schema, the example validates, and the migration is exactly what §12.1 says:

.venv/bin/python - <<'PY'
import glob, json
from jsonschema import validators, FormatChecker
s11  = json.load(open("standards/ver/1.1-draft/ver-record.schema.json"))
validators.validator_for(s11).check_schema(s11)
print("check_schema: OK")
V = validators.validator_for(s11)(s11, format_checker=FormatChecker())
def report(name, path):
    errs = sorted(V.iter_errors(json.load(open(path))),
                  key=lambda e: list(e.absolute_path))
    print(f"{name}: {len(errs)} error(s)")
    for e in errs:
        print("   /" + "/".join(map(str, e.absolute_path)), "|", e.validator)
report("1.1 example", "standards/ver/1.1-draft/example-record-lineage.json")
report("1.0.1 example", "standards/ver/1.0.1/example-record.json")
for f in sorted(glob.glob("conformance/valid/*.json")):
    report(f, f)
PY

Expected: check_schema: OK; the 1.1 example at 0 error(s); the 1.0.1 example at exactly three — /ver_version (const) and /spaces/0/reference, /spaces/1/reference (required); every 1.0.1 conformance/valid/ fixture showing only those two edits, except binary-dtype.json (five: adding /spaces/0/metric and two more on /spaces/0/reference) and redacted-with-proof.json (five: adding two on /metadata/redactions/0 and one on /metadata/normalized/Iptc4xmpExt:PersonInImage); and the four 1.1-draft fixtures in that directory — l3-full-1-1.json, lineage-composed.json, lineage-dangling.json, lineage-exported.json — at 0 error(s).

2 — the hardened bundle path grammar (ADR-0007, finding REV-05):

.venv/bin/python - <<'PY'
import json, re
s11 = json.load(open("standards/ver/1.1-draft/ver-record.schema.json"))
p = s11["$defs"]["portablePath"]
ok, bad = re.compile(p["pattern"]), re.compile(p["not"]["pattern"])
accept = lambda s: bool(ok.search(s)) and not bad.search(s)
for s in ["..\\evil", "C:\\evil", "a\\..\\evil", "a/../b", "a//b", "/a", "a/",
          "", ".", "..", "./a", "a\n", "weights/model.safetensors\n", "a b", "a:b"]:
    print(f"  REJECT {s!r:32} -> {accept(s)}")
for s in ["weights/model.safetensors", "config.json",
          "model-00001-of-00003.safetensors", ".hidden/x"]:
    print(f"  ACCEPT {s!r:36} -> {accept(s)}")
PY

Expected: every REJECT line False, every ACCEPT line True.

3 — the space_id widening, over the grammar rather than over an example:

.venv/bin/python - <<'PY'
import itertools, json, random, re
s101 = json.load(open("standards/ver/1.0.1/ver-record.schema.json"))
s11  = json.load(open("standards/ver/1.1-draft/ver-record.schema.json"))
p101 = re.compile(s101["$defs"]["spaceDescriptor"]["properties"]["space_id"]["pattern"])
p11  = re.compile(s11["$defs"]["spaceDescriptor"]["properties"]["space_id"]["pattern"])
# The 1.0.1 grammar: first label [a-z0-9]+, later labels [a-z0-9-]+ (edge hyphens
# legal), version N.N or N.N.N.
rnd, ids = random.Random(20260823), []
alphabet = "abz09-"
for lab in list(alphabet) + ["".join(p) for p in itertools.product(alphabet, repeat=2)]:
    ids.append(f"org.{lab}/1.0")                       # exhaustive short-label sweep
while len(ids) < 260:                                   # randomized sweep
    first = "".join(rnd.choice("abz09") for _ in range(rnd.randint(1, 6)))
    rest = [
        "".join(rnd.choice(alphabet) for _ in range(rnd.randint(1, 8)))
        for _ in range(rnd.randint(1, 4))
    ]
    ver = f"{rnd.randint(0,99)}.{rnd.randint(0,99)}" + (
        f".{rnd.randint(0,999)}" if rnd.random() < 0.5 else "")
    ids.append(first + "." + ".".join(rest) + "/" + ver)
assert all(p101.fullmatch(i) for i in ids), "generator emitted a non-1.0.1 identifier"
missed = [i for i in ids if not p11.fullmatch(i)]
print(f"{len(ids)} identifiers generated from the 1.0.1 grammar; rejected by 1.1: {len(missed)}")
for i in ["org.-example/1.0", "org.example-/1.0", "acme.my-org.space-/2.1",
          "org.example.-clip/1.0.0"]:
    print(f"  {i:26} 1.0.1={bool(p101.fullmatch(i))} 1.1={bool(p11.fullmatch(i))}")
for i in ["my-org.example.space/1.0", "xn--3e0b707e.example.clip/2.0.1",
          "org.example.clip/1.0.0-rc.1", "org.example.clip/2.1.0+build.7"]:
    print(f"  {i:32} 1.0.1={bool(p101.fullmatch(i))} 1.1={bool(p11.fullmatch(i))}")
PY

Expected: rejected by 1.1: 0; then four 1.0.1-valid identifiers accepted by both, then four 1.1-only identifiers accepted only by 1.1.

4 — every digest in the example recomputes:

.venv/bin/python - <<'PY'
import base64, hashlib, json, math, struct, rfc8785
e = json.load(open("standards/ver/1.1-draft/example-record-lineage.json"))
jcs = lambda o: hashlib.sha256(rfc8785.dumps(o)).hexdigest()
for i, sp in enumerate(e["spaces"]):
    b = sp["model"]["bundle"]
    print(i, "manifest_sha256:", jcs({"files": b["files"]}) == b["manifest_sha256"],
          "| pre-sorted:", b["files"] == sorted(b["files"], key=lambda f: f["path"].encode()),
          "| descriptor_sha256:",
          jcs({k: v for k, v in sp.items() if k != "descriptor_sha256"}) == sp["descriptor_sha256"])
for r in e["metadata"]["raw"]:
    ok = (hashlib.sha256(base64.b64decode(r["bytes"])).hexdigest() == r["sha256"]
          if "bytes" in r else r["sha256"] == r["bytes_ref"]["sha256"])
    print(r["segment"], r["index"], "digest:", ok)
for emb in e["embeddings"]:
    if "vector_b64" in emb:
        want = emb["dim"] * 4 if emb["dtype"] == "fp32" else math.ceil(emb["dim"] / 8)
        print(emb["dtype"], "vector byte length:", len(base64.b64decode(emb["vector_b64"])) == want)
SALT = bytes.fromhex("5f2b9d4c7a10e836c1d94f0b2e7a6538bd41c09e72a5f3861d0b4e97ca25f8d3")
v = rfc8785.dumps("51.4779N")
c = hashlib.sha256(b"VER-REDACTION-COMMITMENT-1" + struct.pack(">Q", len(SALT)) + SALT
                   + struct.pack(">Q", len(v)) + v).hexdigest()
print("commitment reproduces:", c == e["metadata"]["redactions"][0]["commitment_sha256"]
      == e["metadata"]["normalized"]["exif:GPSLatitude"]["commitment_sha256"])
recipe = {"recipe_version": "1", "canonicalization": "rfc8785-jcs",
          "steps": [{"op": "canvas", "width": 128, "height": 48, "background": "#000000"},
                    {"op": "place", "source": "parent-a", "x": 0, "y": 0},
                    {"op": "place", "source": "parent-b", "x": 64, "y": 0}],
          "x-org.example.studio": {"template": "diptych-128x48"}}
print("recipe_sha256:", jcs(recipe) == e["lineage"]["recipe_sha256"]
      == e["provenance"]["chain"][1]["params_sha256"])
print("normalize params_sha256:",
      jcs({"black_point_compensation": False, "cmm": "lcms2", "cpnp_version": "1.0",
           "intent": "relative_colorimetric"}) == e["provenance"]["chain"][3]["params_sha256"])
print("source_bytes_ref == content_hash (E25):",
      e["image"]["source_bytes_ref"]["sha256"] == e["identity"]["content_hash"]["value"])
print("c2pa manifest_sha256 == the c2pa segment's digest:",
      e["provenance"]["c2pa"]["manifest_sha256"]
      == [r for r in e["metadata"]["raw"] if r["segment"] == "c2pa"][0]["sha256"])
print("salt is absent from the Record:",
      "5f2b9d4c" not in json.dumps(e))
PY

Expected: every line True.

Ratification checklist

Nothing here ratifies until every row is resolved. Resolved rows are done; BLOCKING rows stop publication outright.

Decisions — resolved

Deliverables and evidence — blocking

Open votes

At ratification: assign the immutable $id, drop -draft from the filenames, freeze the artifact set into standards/ver/1.1.0/ with a RELEASE.md recording each file's SHA-256, and tag the commit ver/1.1.0 — by the publication checklist in VERSIONING.md §3.3, which is what creates the tag, and only after §3.4's publication bar is met.