§6 Looking ahead — 1.0.x → 1.1

Status: 1.1 is a DRAFT. standards/ver/1.1-draft/ is unratified. All five of its ADRs are now Accepted (23 August 2026 owner review) and the standards track has no open decisions — but ratification is gated on ten blocking deliverable and evidence rows in that directory's RELEASE.md, none of which exists yet. Do not implement against it for production. This section exists so that the shape of the migration is known in advance.

6.1 The rules that will govern it

1. A 1.0 Record stays valid under 1.0.x forever and needs no edit. Nothing in 1.1 re-grades a published Record, there is no flag day, and there is no forced re-ingest. What changed at the owner review is what happens when you choose to migrate.
2. Migrating to 1.1 is a real migration, not a version bump. An earlier revision of the draft promised that a 1.0.1-valid Record needed exactly two edits — declare "1.1", state dim/dtype — because its schema was a superset of 1.0.1 for every shared structure. That promise is withdrawn. It was paid for by leaving the standard's own machine-checkable rules out of the schema, and the owner review reversed the trade: every rule JSON Schema can express is now expressed.

Draft §12.1 is the enumeration — fourteen rows, each with the validator failure pointer it produces — and it is measured, not asserted. Measured against this repository: the 1.0.1 golden example needs two of the fourteen (three failure pointers: /ver_version and one per reference block), and across the ten conformance/valid/ fixtures only three more rows are reached, in two fixtures. The likely shape of your own migration is small — but it is not zero, and it is not two edits.

1. ver_version moves to "1.1" only when you use a 1.1 field. Emitting "1.1" on a Record that uses nothing new gains you nothing and costs you every 1.0 consumer, which will decline it. Emitting "1.0" on a Record that does use a 1.1 field is worse: it invites a 1.0 consumer to parse a document whose shape it does not know.
2. cpnp_version does not move. CPNP-1 is unchanged across the whole of VER 1.x. Every pixel_hash you have computed stays valid and stays comparable. Any change to CPNP is CPNP-2 and therefore VER 2.0, with a dual-publish migration window.
3. The edits most likely to bite you, in the order they will:
   1. Every reference block needs set_manifest_sha256. This is the one edit every 1.0.1-valid Record in this repository needs. A tolerance claim bound only to a URI is a claim about whatever that URI serves today, so 1.1 requires the digest of the reference-set manifest. You will need to publish that manifest, which is why it is also a blocking ratification deliverable.
   2. embedding.dim and dtype become REQUIRED (ADR-0008). The 1.0 profile warns today (VER606), so this one is free if you act now.
   3. **A binary space must declare metric: "hamming", normalization: "none", and tolerance_hamming_max** instead of a cosine tolerance, and a binary embedding may not use the inline vector array. If you have a binary space today it almost certainly declares metric: "cosine", which was legal and unusable.
   4. **redactions[].salted_sha256 becomes commitment_sha256 + commitment_alg + a required state, with a new preimage.** Recompute from the salt; see §5's warning about keeping salts.
   5. A float space's tolerance_cosine must be ≥ 0.99, and every integrity-relevant URI must carry its digest (descriptor_uri ⇒ descriptor_sha256, recipe_uri ⇒ recipe_sha256, checkpoint_uri ⇒ revision).
   6. **A metadata family occupying more than one raw[] entry must carry index on each.**
   7. Seven objects are closed, so an undeclared member inside identity.content_hash/pixel_hash, model, reference, a space's provenance, metadata.trust[], conflicts[].values[] or embeddings[].recipe is now rejected. Put deployment data in extensions (1.1 §13), which exists for exactly this.
4. **Three rules still narrow at the conformance level rather than the schema level**, and the reasons are now stated per rule (1.1 §15.4): the size limits (1.1 §7 — serialized record ≤ 10 MiB, decoded inline raw ≤ 6 MiB, decoded single vector ≤ 6 MiB — which no JSON Schema keyword can express portably; the earlier draft's 16 MiB decoded-raw figure was unreachable inside a 10 MiB document and is corrected), space_id uniqueness (1.1 §11.4 — inexpressible, so VER401 enforces it for the life of VER 1.x), and per-kind preprocessing completeness (VER405, deliberately a warning). An oversized 1.0 Record is 1.1-non-conformant, not 1.1-schema-invalid. The size numbers are unratified and no corpus supports them yet. If your Records run large, say so during ratification — that is what the evidence row is for.

6.2 Producer preparation you can do today

None of this requires 1.1, and all of it makes the eventual move trivial:

• Emit embedding.dim and dtype on every embedding, equal to the descriptor's. Clears VER606 now and satisfies ADR-0008 later.
• Stop minting space_ids under authorities you do not control. 1.1 §11.3 adds descriptor_sha256 binding and §2.2 drafts a registry mechanism (the registry document itself is a ratification item); both assume the authority label means something.
• Publish a reference block — set_uri and tolerance_cosine — and state the preprocessing your space actually uses, for every space you ask anyone to trust. Together those are what E13 means by a "full space descriptor": the complete §6.1 field set, which for a visual space is resize, interpolation, antialias, crop, mean, std, channel_order, and for a text space is tokenizer, tokenizer_sha256, max_length, truncation, casing. Clears VER404 and VER405.
• Keep your weights reproducible, and keep the file list. ADR-0007 does not redefine weights_sha256 — that field keeps annex E29's reading in every release of VER: SHA-256 over an artifact you choose, comparable only within your own output, and you SHOULD document which artifact it was. The reproducible cross-producer pin is the new model.bundle.manifest_sha256: SHA-256 of the RFC 8785 JCS canonicalization of `{files: [{path, byte_length, sha256}]}pre-sorted by path, underbundle_digest_alg: "ver-bundle-manifest/1"`. What you have to do today is retain the list of files your forward pass actually reads — a pipeline that loads a model through a framework cache API often does not know, which is exactly how the reference implementation ended up hashing whatever it found (SC-01, SC-02, SC-03).
• Pin a checkpoint revision. If your checkpoint is remotely resolvable, 1.1 requires model.revision beside model.checkpoint_uri. A mutable branch name means one space_id denotes different weights over time, which violates §6.2 immutability today, not in 1.1 (SC-05).
• Keep every redaction salt you have ever used. The 1.1 commitment is not a rename of salted_sha256; its preimage is different, so the digest must be recomputed from the salt and the value. A discarded salt is a redaction entry that can never be migrated. See §5.
• Record your compute environment somewhere you can retrieve it. 1.1 §9's per-embedding compute block wants `{runtime, runtime_version, precision, device_class}`, and reconstructing it after the fact is guesswork.
• Do not invent extension fields. The record root is closed and stays closed; 1.1 §13 adds a single namespaced extensions object. Vendor fields scattered through closed objects are exactly what that section exists to prevent.

6.3 Consumer preparation

• Version-gate before parsing. Read ver_version first. A 1.0 consumer meeting "1.1" should decline or quarantine, not attempt a partial parse.
• Do not equate unknown with invalid on open value spaces. 1.1 opens provenance.chain[].action (and later perceptual algorithms, source classes, and segment families) to a registry. A consumer meeting an unregistered action must treat it as opaque and keep the Record, not reject it. This is the behaviour ADR-0004 depends on, and it is worth implementing before 1.1 ships.
• Do not read unverifiable as valid. 1.1 §6 adds c2pa.status: "unverifiable" for the case where validation could not be performed. It is not a pass. This is the single most likely 1.1 misread, and it is precisely why the value is ver_version-gated instead of back-published into 1.0. Branch on the machine-readable reason, never on error_detail, which is optional and non-normative.
• Do not read a redaction commitment as proof that a value existed. It binds the producer to a value no later than signing time; it says nothing about what was in the Asset. Verifying one requires the salt, and the protocol for disclosing a salt to an authorized challenger is explicitly **out of scope for VER 1.1** — if you need it, you need something this standard does not supply (1.1 §5.3).
• **Resolve a parent by record_uri or {producer_id, record_id}, never by pixel_hash.** A pixel_hash match is a candidate: distinct Assets that render to one Canonical Buffer share it by design (annex E27). Never use it as a join key, and never compare one across cpnp_version values — which is why 1.1 carries the parent's pixel_hash as {value, cpnp_version}.

6.4 Wire-profile notes (VER-F)

The atproto lexicon org.verstandard.record is a projection of the Record onto a federation transport, with its own lifecycle. It is frozen alongside 1.0.0 at standards/ver/1.0.0/wire-profile/.

• The wire profile has no versioning or negotiation mechanism today (WIRE-15): one unversioned NSID, no capability field. 1.1 §14.1's strategy is a hybrid: the collection NSID stays stable across VER 1.x; verVersion and cpnpVersion become REQUIRED on the wire and are the negotiation signal; identity- and security-critical structures stay closed; and extensibility is exactly one namespaced ext map that a consumer MUST ignore when it does not recognise a key. A new NSID is minted only for a breaking wire major, which does not affect the Record standard — a VER-F 2 lexicon still carries VER 1.x Records.
• Propagate verVersion and cpnpVersion from the Record being projected, never from a class default (WIRE-13, WIRE-14, annex N6). A defaulted cpnpVersion is an assertion about which pixel_hash universe a digest belongs to, made by code that did not check.
• The wire's identity.width/height are Canonical Buffer dimensions (annex E2, WIRE-33). Do not populate them from a pre-orientation source.
• The wire profile is strictly weaker than the Record schema today (WIRE-07): not one hash-bearing lexicon field carries a pattern or a length constraint. Until 1.1 §14.3 lands, **validate every arriving wire record yourself** before letting any field reach a filesystem path, a database key, or a decoder. The one exploitable instance of this — an unvalidated pixelSha256 interpolated into a path — is fixed in this branch (WIRE-06), but the class is open.
• A wire record is not a conformant VER Record (WIRE-25). It carries no Layer 2 content and no conformance level. Treat it as a discovery signal that points at a Record, not as the Record.