§4 Editorial notes (non-normative)

These items are recorded for completeness. None changes a requirement, none is enforced by the conformance profile, and — as of 1.0.1 — none uses an RFC 2119 keyword in the capitalized form that would make it normative, outside a verbatim quotation of the base specification (N2 quotes §4's “Producers MUST execute the following steps in order”; that MUST is the specification's, not this note's). Where these notes use words like “should” or “recommended” they carry their ordinary English meaning, per RFC 8174. A requirement that belongs in this annex belongs in an E-item: N4, N5 and N6 previously carried capitalized keywords and no longer do, and the elided-segment prohibition that previously sat inside the editorial item E26 now lives in E11, where the byte-exactness rule it qualifies lives.

N1 — Acquisition method list (SPEC-20). §9 writes the acquisition methods as camera_capture|http_fetch|user_upload|dataset_import|…, whose trailing ellipsis suggests an open set, while the schema closes the enum and adds an other sentinel the prose never mentions. Read §9 as camera_capture|http_fetch|user_upload|dataset_import|other. The enum is closed in 1.0; a new method requires a schema revision, or the registry mechanism drafted for 1.1.

N2 — §4's step count (SPEC-24). §4 says “Producers MUST execute the following steps in order” over an eight-item list whose last two items are not executable steps: item 7 defines the Canonical Buffer and item 8 states the pixel_hash formula. There are six normative steps plus two definitional clauses. Cross-references to “§4 step 8” (as in §5) remain valid and continue to denote the pixel_hash formula; they are not renumbered here, because renumbering a published document's cross-references by annex would break every citation already in the wild.

N3 — Alpha is pixel data (SPEC-25). §2 lists “alpha semantics” among render-affecting metadata. The alpha channel is pixel data carried in the image raster, not metadata. Read §2's definition as: render-affecting metadata is EXIF Orientation and the embedded ICC profile; the alpha channel is likewise resolved and consumed by CPNP-1 (§4 step 5). The substance is unchanged; the category error is not worth propagating.

N4 — model.architecture (SCHEMA-08). §6.1 lists four model attributes — family, architecture, checkpoint, weights_sha256 — while the schema requires three; architecture is optional. The prose is read descriptively: stating architecture is good practice, since it is the field that distinguishes ViT-B/16 from ViT-L/14 when checkpoint strings are opaque, and the golden example does carry it. This note imposes nothing: promoting architecture to required is a tightening, it is deferred past 1.0.x, and until it happens a descriptor that omits it is fully conformant. (Earlier drafts of this note used capitalized RFC 2119 keywords, which would have made an editorial item normative. The substance is unchanged; the false normativity is removed.)

N5 — tolerance_cosine floor (SCH-20). The schema admits any tolerance_cosine in (0, 1], so a space may declare 0.0001 — a conformance bar everything clears — while §6.2 recommends ≥ 0.999 for fp32 profiles. As practical guidance, and imposing nothing: an fp32, fp16 or bf16 space declaring a tolerance below 0.99 is almost certainly declaring a bar it does not mean, and a quantized (int8, binary) space with a lower tolerance does well to justify it in its reference block. Note also that §6.2's test is a mean over the reference set: an implementation with 999 vectors at 1.0 and one at 0.0 passes a 0.999 mean tolerance. Turning the floor into a requirement is a tightening over structure that 1.0.1 shares with 1.0.0, so it is not something a corrective release can do — the 1.1 draft carries it, together with the percentile and worst-case tolerance fields that make the mean test meaningful.

N6 — Wire-profile notes (WIRE-28, WIRE-33, and the remaining VER-F findings). The VER-F federation lexicon (org.verstandard.record.lexicon.json) is a projection of the VER Record onto an atproto collection; it is a separate artifact with its own defects, and this annex does not govern it — which is why this note states no requirement about it and, since 1.0.1, uses no capitalized RFC 2119 keyword. Two of its defects are worth naming because they touch fields this annex defines. First, the wire record's identity.width/height: E2 fixes those values, in the Record, as the Canonical Buffer's dimensions, so a projection that fills them from a pre-orientation source produces a wire record that disagrees with the Record it projects. Second, verVersion/cpnpVersion: E10 makes cpnp_version the marker of which pixel_hash universe a digest belongs to, so a projection that defaults those fields instead of carrying them across strips a digest of the one thing that says what it can be compared with. Both are constraints on the wire profile, and they take effect when the wire profile adopts them — the 1.1 draft's VER-F section is where that happens. The full set of wire-profile findings — versioning and negotiation, constraint parity with this schema, privacy-mode semantics, tombstones and retraction, signed wire records — is catalogued in docs/standards/VER-1.0-errata.md and drafted in standards/ver/1.1-draft/.