Skip to content
VERASPEC
Repository
specificationdraft

VER 1.1 — DRAFT

The unratified 1.1 draft: registry, lineage, model bundle manifests, redaction commitments, size limits and the revised wire profile.

Start readingSource
Contents
  1. OverviewVisual Embedding Record 1.1 · Working Draft · 23 August 2026 (revision 2, post owner review)
  2. §1Scope and compatibility postureVER 1.1 adds representational capacity to the VER Record.
  3. §2The VER registry, and the provenance action value spaceVER 1.0 closes seventeen value spaces as JSON Schema enums — eighteen enum keywords, of which two declare dtype identically on the space descriptor and on the embedding — while 1.0 §5 uses registry language (“Registered perceptual algorithm
  4. §3Lineage (ADR-0005)VER 1.0 records what a pipeline did to an Asset (provenance.chain) and what a signer asserted about it (C2PA), but nothing about where the Asset came from when it was produced from other Assets.
  5. §4Model bundle manifests (ADR-0007)1.0 §6.1 says “Weight pinning is mandatory” and the schema constrains weights_sha256 to 64 hex characters.
  6. §5Redaction (ADR-0006 — decided)1.0 §7.5's literal { redacted: true, reason, salted_sha256 } is rejected by the metadata.redactions[] schema (which requires field and forbids redacted) and accepted by the unconstrained metadata.normalized object.
  7. §6C2PA: unverifiable1.0 §9 imposes an unconditional MUST — “when a manifest is present it MUST be validated” — over a three-value status vocabulary that has no term for the common outcome: a well-formed manifest whose validation could not be completed.
  8. §7Size limits1.0 §1 through 1.0 §14 contain no bound of any kind: no maximum Record size, no cap on inline base64, no maxItems anywhere.
  9. §8Richer conformance evidence1.0 §6.2 defines conformance to a space as a mean cosine similarity against published reference vectors.
  10. §9Per-embedding compute1.0 §6.2 absorbs GPU, CUDA, TensorRT, and ONNX-runtime nondeterminism into a tolerance.
  11. §10Metadata carriageMulti-segment metadata families are common — multi-APP1 EXIF, Extended XMP spanning several markers, multi-chunk iCCP — and 1.0's raw[] entries carry no ordinal, so reassembly depends on array order alone (E11).
  12. §11SpacesVER 1.0's kind is visual | text | fused, and 1.0 §8 requires a contextual embedding to carry “a text-space space_id”.
  13. §12Embedding dim and dtype become REQUIRED (ADR-0008)vector_b64 is documented as “dtype-tagged via the embedding's dtype field” while dtype is optional, and vector_ref names a byte_length with no rule relating it to dim × sizeof(dtype).
  14. §13Record-level extensionsVER 1.0's Record root is closed and no extension syntax exists anywhere in the standard, so a Producer cannot attach a single deployment field to a conformant Record.
  15. §14VER-F wire profile (DRAFT)The VER-F federation profile projects a Record onto an atproto collection (org.verstandard.record).
  16. §15Schema delta summaryAdditions, widenings and encodings relative to ver-record-1.0.1.json.
  17. §16Not in 1.1The following are recorded here so that their absence is a decision rather than an oversight.
  18. §17Open questions blocking ratificationADR-0006 — whether the redaction commitment is mandatory — is closed (§5).