Decision required to migrate launcher identity literals without inventing an ID
The owner has requested UUIDv8 for launch-scaffolder. At standards main 3108c1b, the normative DEED ABNF v1.1.0 accepts #u8"domain:name" as ADR-008 profile C alongside #u5. The canonical launcher/launcher-standard_praxis.deed still says :beholding-chora #u5"estate/chora"; so do the provisioning deed and canonical conformance fixtures. Its DEED grammar prose still illustrates UUIDv5 in the praxis identity field. Under ADR-008's one declaration site and registered-domain rule, a downstream generator must not invent an #u8"estate:chora" or other plausible spelling: the v8 digest would identify a different object unless the chora owner registers a mapping.
The consumer's parser is being upgraded additively: it can read both v5 and v8 (including strict profile-C domain syntax), with upstream corpus v1.1 fixtures pinned and the old minted launcher preserved. That is not yet a license to change the emitted :beholding-chora or the 21 per-app descriptors.
Requested ruling/AC:
- The estate chora's owning authority registers an exact profile-C
domain:name preimage for the canonical chora, states how it aliases or supersedes existing #u5"estate/chora", and identifies the declaration site and effective version. Do not choose an ID merely from its appearance.
- The owning standard's machine-readable deed and prose/identity table move in lockstep, with positive and deliberately invalid conformance fixtures;
#u5 remains readable for historical launchers through a stated overlap/retirement rule.
- Once merged, launch-scaffolder updates new emission only, re-mints the currency-locked fixture, keeps the frozen pre-change fixture, and proves both readers agree on all non-identity metadata. Any per-app descriptor conversion still waits for the separate vocabulary ruling (standards#1226); canonical launcher deed alignment is standards#1225.
Refs ADR-008 (D305/D320), 1-formats/deed/spec/abnf/deed.abnf v1.1.0, launcher/launcher-standard_praxis.deed, hyperpolymath/launch-scaffolder#42/#65. No UUID preimage or canonical file was modified by this request.
Decision required to migrate launcher identity literals without inventing an ID
The owner has requested UUIDv8 for launch-scaffolder. At standards
main3108c1b, the normative DEED ABNF v1.1.0 accepts#u8"domain:name"as ADR-008 profile C alongside#u5. The canonicallauncher/launcher-standard_praxis.deedstill says:beholding-chora #u5"estate/chora"; so do the provisioning deed and canonical conformance fixtures. Its DEED grammar prose still illustrates UUIDv5 in the praxis identity field. Under ADR-008's one declaration site and registered-domain rule, a downstream generator must not invent an#u8"estate:chora"or other plausible spelling: the v8 digest would identify a different object unless the chora owner registers a mapping.The consumer's parser is being upgraded additively: it can read both v5 and v8 (including strict profile-C domain syntax), with upstream corpus v1.1 fixtures pinned and the old minted launcher preserved. That is not yet a license to change the emitted
:beholding-choraor the 21 per-app descriptors.Requested ruling/AC:
domain:namepreimage for the canonical chora, states how it aliases or supersedes existing#u5"estate/chora", and identifies the declaration site and effective version. Do not choose an ID merely from its appearance.#u5remains readable for historical launchers through a stated overlap/retirement rule.Refs ADR-008 (D305/D320),
1-formats/deed/spec/abnf/deed.abnfv1.1.0,launcher/launcher-standard_praxis.deed, hyperpolymath/launch-scaffolder#42/#65. No UUID preimage or canonical file was modified by this request.