Keep rulebooks immutable and endpoints reliable; evolve by minting new IDs and operate without blocking payloads
7E. Versioning and evolution
Principles.
- Manifest rotation. Any policy change MUST mint a new
manifest_id. Older manifests remain published for full replay. - Endpoint stability. Paths stay stable; new optional query params can be added without breaking older clients.
- Compatibility. Additional fields in
manifests.jsonorenvelopes.jsonlMUST NOT change the meaning of existing fields or the canonical subset contract.
Pinned-digest reminder (illustrative).
# compute a stable pin over the exact manifest bytes
manifest_sha256 := sha256(manifest_bytes)
manifest_pin := "sha256=" + manifest_sha256
# rotation rule
# - never edit bytes of an existing manifest_id
# - publish a new manifest_id when policy changes
# - keep prior manifests online for replay
7F. Operational notes
Availability & behavior.
- Read-only surfaces. Discovery endpoints are informational; outages MUST NOT block payload delivery or continuity.
- Scope naming. Prefer stable, human-readable names (e.g.,
default,orders,feed-alpha). - Fork handling. If a fork is intentionally created, publish a short
fork.txtinside the evidence bundle describing procedure and recovery. - Rollover markers. When
(U,W)epochs roll, expose a stamped checkpoint near the boundary to simplify replay.
Continuity & stamps (recap).
# append-only, single-link chain
stamp := "SSMCLOCK1|<UTC_ISO>|nonce=<...>|sha256=" + HEAD + "|prev=<HEX or NONE>"
Caching posture (operator hint).
- manifest/<manifest_id> : long TTL (immutable), strong validators
- checkpoint : short TTL, conditional requests (ETag/Last-Modified)
- evidence : deterministic archive ordering for reproducible digests
Navigation
Previous: SSM-NET — Well-known endpoints (7C–7D)
Next: SSM-NET — Well-known endpoints: Fetch, Pinning & Offline Replay (7G)
SHUNYAYA 