§13 Record-level extensions

VER 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. 1.0 §13's “reserved extension points” names future features, not a mechanism.

extensions is an optional record-level object. Its keys are reverse-DNS namespaces controlled by the extension's author (^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+$); values are unconstrained.

• A Consumer MUST ignore namespaces it does not recognize, MUST preserve them when re-serializing a Record it did not author, and MUST NOT let them affect conformance in either direction.
• An extension MUST NOT restate, contradict, or substitute for a standard member. A Producer that carries pixel_hash in an extension namespace, or uses one to signal a conformance level, is non-conformant. A salt MUST NOT be carried here (§5.3).
• Extensions are not an escape hatch for the registry (§2): a new provenance action is a namespaced action value, not an extensions entry.

A single record-level extension point is deliberate. Per-object extension surfaces (on spaceDescriptor, embedding, metadata) were considered and rejected for this draft: they multiply the places a Consumer must defend against, and the record-level object can carry a pointer into the structure it annotates. It is also what makes §15.2's closures affordable — a Producer that needs a member the standard does not define has one legal place to put it.