From 79e47f4ee0bcd57467859a20c8c5f2b721c3e8f6 Mon Sep 17 00:00:00 2001 From: Andrew Peris Date: Mon, 26 Oct 2026 17:04:40 -0400 Subject: [PATCH 1/5] docs: accept stable record ID application profile --- CHANGELOG.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 7b1b249..6a25526 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,11 +11,12 @@ compatible, or editorial. ## Unreleased -- Propose stable record IDs 0.1.0 in Draft RFC 0009 (new additive family), - built on RFC 9562 UUIDv4 with standard hyphenated lowercase suffixes, pinpoint - standards references, and synthetic syntax/version/variant and inventory/reference - conformance evidence. Prefix and identity lifecycle rules remain application policy. No - existing or released contract semantics change; adoption remains undecided. +- Accept stable record IDs 0.1.0 in RFC 0009 as a new additive application + profile, built on RFC 9562 UUIDv4 with standard hyphenated lowercase suffixes, + pinpoint standards references, and synthetic syntax/version/variant and + inventory/reference conformance evidence. Andrew owns the restricted, + version-controlled inventory and reviewed allocation process. The profile is + unreleased; existing released contract semantics remain unchanged. - Clarified the unreleased Comic Manifest 1.0.0 candidate's (#95 prerequisite) detached approval time bounds: decision time is inclusive, expiry is exclusive From 7ac2738f0a1cb64bb629f585a0e2649204dff75d Mon Sep 17 00:00:00 2001 From: Andrew Peris Date: Mon, 26 Oct 2026 17:04:45 -0400 Subject: [PATCH 2/5] docs: accept stable record ID application profile --- rfcs/0009-stable-record-ids.md | 141 ++++++++++++++++++--------------- 1 file changed, 77 insertions(+), 64 deletions(-) diff --git a/rfcs/0009-stable-record-ids.md b/rfcs/0009-stable-record-ids.md index 995dd34..0cb11dd 100644 --- a/rfcs/0009-stable-record-ids.md +++ b/rfcs/0009-stable-record-ids.md @@ -1,10 +1,10 @@ # RFC 0009: Stable record IDs -- Status: Draft — proposal only; merge does not itself accept this contract +- Status: Accepted for application use by owner on 2026-10-26; unreleased - Authors: @andrewperis - Created: 2026-10-24 - Contract families: identifiers -- Compatibility: New additive proposed contract, version 0.1.0; no stable predecessor +- Compatibility: New additive accepted application profile, version 0.1.0; no stable predecessor - Supersedes: None - Superseded by: None - Constitution version: 1.0.0 @@ -16,16 +16,19 @@ ## Summary -Propose a reusable application-level naming and identity profile built on +Define an accepted, reusable application-level naming and identity profile built +on [RFC 9562](https://www.rfc-editor.org/rfc/rfc9562.html), using UUIDv4 for character, location, and relationship records. An ID names the same logical record across edits, display-name changes, and repository moves. It does not identify exact content bytes or confer authority. -The requirements below describe the proposed 0.1.0 contract, not an accepted -standard, production allocation, or publication approval. This repository RFC -is a local proposal, not an IETF submission, endorsement or standards-track -document. A broader proposal could be considered later through a separate -review and submission decision; no external submission is part of this work. +The requirements below define accepted application-profile semantics at +version 0.1.0. This RFC records the owner-approved decision; its review and merge +remain required, and neither the RFC change nor this status releases a bundle, +starts a consumer migration, issues IDs, or approves publication. This is a +local application profile, not an IETF submission, endorsement or +standards-track document. A broader proposal would require a separate review +and submission decision; no external submission is part of this work. ## Motivation and existing-contract inventory @@ -45,13 +48,13 @@ invent a random-number encoding; it does not alter those URNs or their meanings. Existing prompt, package, schema, production and artifact identities retain their own meanings and namespaces. -Reuse that safe ASCII repertoire, exact string comparison, and independent -version/content identity rather than add a resolver protocol. Those existing -schemes do not specify persistent record issuance, collision or rename rules; -therefore a small separate proposal is necessary. No source ID is converted, -reserved, replaced or reinterpreted by this RFC. +This profile reuses that safe ASCII repertoire, exact string comparison, and +independent version/content identity rather than add a resolver protocol. Those +existing schemes do not specify persistent record issuance, collision or +rename rules; therefore a small separate application profile is necessary. No +source ID is converted, reserved, replaced or reinterpreted by this RFC. -## Specification (proposed) +## Specification (accepted application profile 0.1.0) ### Standards basis and application rules @@ -86,8 +89,9 @@ required version/variant bits. Merely inserting hyphens into arbitrary random bytes is insufficient; a name/content hash with overwritten version bits is not UUIDv4 generation. Schema validation can check syntax, version and variant, but cannot establish random generation. -The prefix `record` and three kind tokens are proposed only. This RFC neither -reserves nor changes an existing released namespace. IDs are opaque: names, +The prefix `record` and three kind tokens are specific to this accepted +application profile. This RFC neither reserves nor changes an existing released +namespace. IDs are opaque: names, slugs, file paths, chronology, ownership and classification MUST NOT be encoded. Consumers MUST reject malformed or noncanonical profile IDs rather than trim, case-fold, normalize or repair them. Lowercase is the producer's serialization @@ -106,20 +110,22 @@ alone cannot establish it. ### Issuance and collisions -Only an authorized record owner MAY issue an ID. The issuer MUST use a -UUIDv4 generator backed by a CSPRNG as required by this profile, check the -complete candidate against the authoritative inventory of issued and retired IDs, and atomically reserve -it with its kind before committing a new record. A reservation collision MUST -cause fresh generation and another reservation attempt. If the inventory or -atomic reservation is unavailable, issuance MUST fail without publishing a -record. Offline candidates are unissued until reservation succeeds. Consumers -MUST NOT mint IDs merely because they encounter a missing reference. - -The inventory may be maintained by an existing transactional store or serialized -owner-reviewed allocation process; no new service or framework is prescribed. -The accountable inventory owner and cross-repository reservation workflow must -be selected before adoption. Randomness reduces collision probability; it does -not replace a uniqueness check. Retired IDs remain reserved forever. +Only an authorized record owner MAY issue an ID. Andrew (@andrewperis) is the +accountable owner of the private, version-controlled record-ID inventory and +the serialized allocation process. Each candidate MUST be generated by a +UUIDv4 generator backed by a CSPRNG, checked against the complete issued and +retired inventory, and included in a reviewed pull request. Before any +candidate allocation, the change MUST document legacy-ID compatibility and a +duplicate check. A candidate is unissued while its pull request is open; it +becomes issued only when the reviewed change is merged. A collision MUST stop +the affected allocation and be escalated to the accountable owner. Do not +silently overwrite, merge or renumber an already-issued ID. Consumers MUST NOT +mint IDs merely because they encounter a missing reference. + +The inventory is maintained in the restricted Lore repository through +serialized, owner-reviewed pull requests; no new service or framework is +prescribed. Randomness reduces collision probability; it does not replace a +uniqueness check. Retired IDs remain reserved forever. A conflict discovered after issuance MUST stop import/update and be escalated to the accountable owner. Do not silently overwrite, merge or renumber an @@ -140,7 +146,7 @@ reviewed and do not make historical references name a different entity. A record reference carries the full ID. Relationships have their own persistent ID and explicit endpoint IDs; they MUST NOT derive identity from endpoint order, names or a hash of the current relationship text. Endpoints in the minimal -examples are characters or locations. This proposal does not define predicates, +examples are characters or locations. This profile does not define predicates, cardinality, directionality or a relationship payload schema. An authorized validator MUST check references against its complete permitted @@ -160,7 +166,7 @@ conversion. Do not add record fields to existing closed context schemas. ## Conformance examples All values in the [cases](0009-stable-record-ids/cases.json) are fabricated. -The [proposal-local schema](0009-stable-record-ids/id.schema.json) validates only +The [RFC-local schema](0009-stable-record-ids/id.schema.json) validates only ID strings; it intentionally has no canonical `$id` and is not a released schema. The UUIDv4 fixtures were generated solely for synthetic tests with Python `uuid.uuid4()`; they are not issued or reserved record IDs. The cases exercise @@ -171,31 +177,32 @@ Run `node --test tests/stable-record-ids.test.cjs` or `npm test`. ## Compatibility and migration -This introduces proposed 0.1.0 semantics only. Released schemas, bundles, tags, -source IDs and artifact namespaces remain unchanged. No consumer adopts it by -merging this proposal. Candidate consumers are record storage/validation and -reference-producing tools; Context Builder/Prompt SDK would require a separately -reviewed integration only if they consume persistent record references. -@andrewperis owns the decision; affected consumer maintainers must confirm the -inventory and reservation process before acceptance. - -Before adoption: inventory existing schemes and references without disclosing -protected records; prefer preserving compatible issued identities over blanket -renumbering; document explicit mappings for incompatible legacy IDs; validate -references and collisions; obtain owner/consumer review; then publish the -accepted specification, canonical versioned schema and immutable release under -[versioning policy](../docs/versioning.md). No existing consumer migration or -dated support window is activated by this proposal. Adoption must set a dated -rollout/rollback window and preserve old references during that window. A rollback -must retain reservations and mappings so issued IDs are never recycled. +This adds accepted 0.1.0 semantics as an unreleased additive family. Released +schemas, bundles, tags, source IDs and artifact namespaces remain unchanged. +Merging this RFC does not publish a release or activate consumer migration. +Candidate consumers are record storage/validation and reference-producing tools; +Context Builder/Prompt SDK would require a separately reviewed integration +only if they consume persistent record references. +@andrewperis owns the decision; affected consumer maintainers must review any +integration before using the profile. + +Before a production consumer adopts this profile, inventory its existing +schemes and references without disclosing protected records; preserve compatible +issued identities; document mappings for any incompatible legacy IDs; validate +references and collisions; and obtain owner/consumer review. Any later release +must follow the [versioning policy](../docs/versioning.md). This RFC does not +activate a consumer migration or dated support window. If a consumer later needs +a migration, its separately reviewed plan must define rollout and rollback +dates and retain reservations and mappings so issued IDs are never recycled. ## Security and privacy Even random IDs can correlate private activity. Public material MUST use wholly -synthetic IDs and examples; do not copy private IDs, names, paths, links, excerpts -or mappings into public fixtures or logs. Inventory access and error detail must -respect classification. An ID's shape proves neither ownership nor permission. -No private record allocation or private validator work is part of this proposal. +synthetic IDs and examples; do not copy private IDs, names, paths, links, +excerpts or mappings into public fixtures or logs. Inventory access and error +detail must respect classification. An ID's shape proves neither ownership nor +permission. The private inventory and validation evidence remain in restricted +systems; Codex fixtures contain synthetic examples only. ## Rights, provenance, accessibility, and portability @@ -214,18 +221,24 @@ This RFC does not assess private content or complete a broader conformance item. identity on ordinary edits or moves. - Sequential IDs: require coordinated enumeration and reveal allocation order; UUIDv4 suffixes keep the same explicit uniqueness check without that leakage. -- A custom 32-hex random suffix: superseded in this proposal by standard +- A custom 32-hex random suffix: superseded in this profile by standard hyphenated UUIDv4 with explicit version and variant, for interoperability. - Introduce a resolver/registry service or full record taxonomy: unnecessary for this narrow contract; implementation and payload semantics remain separate. -## Implementation plan and decisions needed - -Review the application profile, uniqueness scope, retirement/reference rules -and inventory owner. UUIDv4 is the proposed standard building block; application -adoption and any future broader RFC remain separate decisions. -Confirm whether any existing issued scheme must be retained before accepting. -Only after explicit acceptance should maintainers promote the proposal, choose -its stable version, implement issuance in the owning consumer, and plan release. -The PR should be ready for review while the RFC remains Draft. Do not merge, -release, tag, allocate real IDs or change public canon as part of this task. +## Accepted operational status + +The application profile is accepted at 0.1.0. Andrew (@andrewperis) is +accountable for the restricted, version-controlled inventory. Allocations are +serialized through reviewed pull requests, and candidates remain unissued until +their reviewed change merges. Each allocation must first document compatibility +with legacy IDs and a full duplicate check. An already-issued conflict stops +the affected allocation and is escalated; no silent conversion or renumbering +is allowed. + +This status does not create a canonical released schema, immutable bundle or +tag, migration window, production integration, or public creative publication. +The RFC-local schema and synthetic fixtures remain bounded to this RFC; +any release or consumer migration requires its normal separate review and +versioning steps. No private record names, IDs or allocation evidence belong in +this repository. From 9e9ee71bf187c28356d17f9e5275d4bf988f0e8c Mon Sep 17 00:00:00 2001 From: Andrew Peris Date: Mon, 26 Oct 2026 17:04:49 -0400 Subject: [PATCH 3/5] docs: list accepted stable ID profile --- rfcs/README.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/rfcs/README.md b/rfcs/README.md index dd45eb3..9d3ddec 100644 --- a/rfcs/README.md +++ b/rfcs/README.md @@ -25,6 +25,7 @@ RFC filenames use four-digit numbers and a concise kebab-case title: a proposal. Allocate the next number when the pull request opens; numbers are never reused. -Accepted candidates include Prompt Definition v1 (RFC 0001), Provider Execution -v1 (RFC 0002), Context Package v1 (RFC 0003), and Structured Output v1 (RFC -0004). +Accepted decisions include Prompt Definition v1 (RFC 0001), Provider Execution +v1 (RFC 0002), Context Package v1 (RFC 0003), Structured Output v1 (RFC 0004), +and the unreleased UUIDv4 application profile 0.1.0 (RFC 0009). RFC 0009 has no +released schema, consumer migration, or production integration yet. From 2262cf27f944d0f7826e8594acaa2c7a011c1e64 Mon Sep 17 00:00:00 2001 From: Andrew Peris Date: Mon, 26 Oct 2026 17:04:55 -0400 Subject: [PATCH 4/5] docs: describe accepted record ID profile --- specs/ids/README.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/specs/ids/README.md b/specs/ids/README.md index c28c911..956e364 100644 --- a/specs/ids/README.md +++ b/specs/ids/README.md @@ -3,6 +3,8 @@ Stable identifier formats, namespaces, uniqueness rules, normalization, and human-readable naming conventions belong here. -[RFC 0009](../../rfcs/0009-stable-record-ids.md) proposes a UUIDv4 application profile for -stable record IDs for characters, locations and relationships. It is Draft, not an accepted -contract or authority to allocate production IDs. +[RFC 0009](../../rfcs/0009-stable-record-ids.md) defines the accepted 0.1.0 +UUIDv4 application profile for stable character, location and relationship +record IDs. It is unreleased: the proposal-local schema is not a canonical +released schema, and production allocations still require the private +owner-reviewed inventory process. From 3cd36f9586215c97e2cc20136c18e3f99dcfb52b Mon Sep 17 00:00:00 2001 From: Andrew Peris Date: Mon, 26 Oct 2026 17:24:17 -0400 Subject: [PATCH 5/5] docs: preserve release gate for production ID use --- rfcs/0009-stable-record-ids.md | 37 ++++++++++++++++++++-------------- specs/ids/README.md | 4 +++- 2 files changed, 25 insertions(+), 16 deletions(-) diff --git a/rfcs/0009-stable-record-ids.md b/rfcs/0009-stable-record-ids.md index 0cb11dd..15b1cf0 100644 --- a/rfcs/0009-stable-record-ids.md +++ b/rfcs/0009-stable-record-ids.md @@ -113,14 +113,17 @@ alone cannot establish it. Only an authorized record owner MAY issue an ID. Andrew (@andrewperis) is the accountable owner of the private, version-controlled record-ID inventory and the serialized allocation process. Each candidate MUST be generated by a -UUIDv4 generator backed by a CSPRNG, checked against the complete issued and -retired inventory, and included in a reviewed pull request. Before any -candidate allocation, the change MUST document legacy-ID compatibility and a -duplicate check. A candidate is unissued while its pull request is open; it -becomes issued only when the reviewed change is merged. A collision MUST stop -the affected allocation and be escalated to the accountable owner. Do not -silently overwrite, merge or renumber an already-issued ID. Consumers MUST NOT -mint IDs merely because they encounter a missing reference. +UUIDv4 generator backed by a CSPRNG, checked against the complete issued, +reserved and retired inventory, and included in a reviewed pull request. Before +any candidate allocation, the change MUST document legacy-ID compatibility and +a duplicate check. A candidate remains unissued while its pull request is open. +An approved merge records it as a private reservation; it does not authorize +production issuance or use. Production use requires an immutable contract +release and separately reviewed consumer adoption under the +[change-control policy](../docs/change-control.md). A collision MUST stop the +affected allocation and be escalated to the accountable owner. Do not silently +overwrite, merge or renumber an already-issued ID. Consumers MUST NOT mint IDs +merely because they encounter a missing reference. The inventory is maintained in the restricted Lore repository through serialized, owner-reviewed pull requests; no new service or framework is @@ -180,6 +183,8 @@ Run `node --test tests/stable-record-ids.test.cjs` or `npm test`. This adds accepted 0.1.0 semantics as an unreleased additive family. Released schemas, bundles, tags, source IDs and artifact namespaces remain unchanged. Merging this RFC does not publish a release or activate consumer migration. +Production consumers MUST wait for an immutable release and separately reviewed +adoption; a private reservation does not satisfy the release gate. Candidate consumers are record storage/validation and reference-producing tools; Context Builder/Prompt SDK would require a separately reviewed integration only if they consume persistent record references. @@ -228,13 +233,15 @@ This RFC does not assess private content or complete a broader conformance item. ## Accepted operational status -The application profile is accepted at 0.1.0. Andrew (@andrewperis) is -accountable for the restricted, version-controlled inventory. Allocations are -serialized through reviewed pull requests, and candidates remain unissued until -their reviewed change merges. Each allocation must first document compatibility -with legacy IDs and a full duplicate check. An already-issued conflict stops -the affected allocation and is escalated; no silent conversion or renumbering -is allowed. +The application profile is accepted at 0.1.0 but remains unreleased. Andrew +(@andrewperis) is accountable for the restricted, version-controlled inventory. +Allocations are serialized through reviewed pull requests, and candidates +remain unissued while under review. An approved merge records the candidate as +a private reservation; production issuance and use still require an immutable +release and separately reviewed consumer adoption. Each allocation must first +document compatibility with legacy IDs and a full duplicate check. An +already-issued conflict stops the affected allocation and is escalated; no +silent conversion or renumbering is allowed. This status does not create a canonical released schema, immutable bundle or tag, migration window, production integration, or public creative publication. diff --git a/specs/ids/README.md b/specs/ids/README.md index 956e364..157328f 100644 --- a/specs/ids/README.md +++ b/specs/ids/README.md @@ -7,4 +7,6 @@ human-readable naming conventions belong here. UUIDv4 application profile for stable character, location and relationship record IDs. It is unreleased: the proposal-local schema is not a canonical released schema, and production allocations still require the private -owner-reviewed inventory process. +owner-reviewed inventory process. Production use also requires an immutable +contract release and separately reviewed consumer adoption under the +[change-control policy](../../docs/change-control.md).