#!RFC-AI/2;id=9;draft=1;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=f78ef8b4c5561e26bff8d72bfc46eff79646c1e07ca3fa9d9d3b282ae2c25651
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 9 — DOCUMENT IDENTITY, VERSIONING, AND PUBLICATION GOVERNANCE
Status: DRAFT — CEO REVIEW REQUIRED; NOT ACTIVE POLICY
Revision: Draft 1
Date (UTC): 2026-10-29
Stream: Peostectica / RFC-AI Editorial
Author: RFC-AI Founder Drafting Process
Approver: CEO or explicitly delegated publication authority
Updates: Proposed replacement for conflicting RFC-AI numbering clauses when approved; no automatic change to currently approved policy.

ABSTRACT
This proposed RFC-AI defines one simple, sequential document identifier; separate draft and published revision labels; a verifiable editorial workflow; authoritative source and derived renderings; immutable approved edition snapshots; correction, update and replacement relationships; and consistent implementation across websites, Readers, APIs, and AI workers. It adopts applicable principles from traditional RFC governance but establishes a separate, private RFC-AI series. No draft grants itself authority.

1. SCOPE AND NORMATIVE WORDS
1.1 This specification governs RFC-AI documents, their metadata, numbering, drafts, approved editions, registries, citations, lifecycle, archival records, and representations. It does not control IETF RFCs or independently alter existing company policy before approval.
1.2 The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT and MAY, when in uppercase, are interpreted in the sense of IETF BCP 14 (RFC 2119 as clarified by RFC 8174). They apply to the RFC-AI system once this document has been approved.
1.3 Every document MUST show its approval state separately from its version or edition label. A header's self-reported state is not evidence of approval.

2. DOCUMENT IDENTITY — ONE HUMAN SYSTEM
2.1 The sole active human-facing identifier syntax is RFC-AI N, where N is a positive decimal integer without leading zeroes. The existing eight documents are assigned RFC-AI 1 through RFC-AI 8, and this proposal is RFC-AI 9. Subsequent identifiers are consecutive, allocated by an authoritative atomic registry transaction.
2.2 An identifier MUST refer to exactly one document subject and MUST NOT be reused for an unrelated subject. No nine-digit padding, hundred-step gaps, or competing public aliases are permitted in the active system.
2.3 A document's number is NOT its draft count, publication edition, software version, status, priority, release date, or authority level.
2.4 The registry MUST reject duplicate allocation, conflicts, invalid syntax, and citation to unknown document identities. A number allocated to a withdrawn item MUST NOT be reassigned; the registry MUST record the disposition transparently.
2.5 Identifiers and filenames MUST follow the same canonical naming: RFC-AI N.txt. Directory paths and public URLs MAY use URL-escaped or lowercase route forms but MUST display the canonical name, and MUST resolve unambiguously.

3. REVISION AND EDITION LABELS
3.1 Unapproved revisions use Draft N (Draft 1, Draft 2, ...) with a strictly increasing positive integer per RFC identity. Drafts are NOT company policy, irrespective of their number.
3.2 A first approved publication uses Edition 1.0. Later approved corrections or compatible clarifications MAY use Edition 1.1, Edition 1.2, etc. An approved material revision that significantly changes semantics or obligations uses Edition 2.0, 3.0, etc. This is an RFC-AI editorial convention, NOT IETF or Semantic Versioning compliance.
3.3 Increments MUST be assigned from editorial change assessment; arithmetic alone MUST NOT infer compatibility, safety, consensus, or authority.
3.4 Every published edition MUST be pinned to exact immutable bytes and a cryptographic digest. Editing those bytes in place is forbidden. A new edition or an explicitly classified erratum is required.
3.5 Software components (Reader, API, conference broker) MAY use a separate software SemVer. Their software versions MUST NOT be mistaken for RFC-AI edition identifiers.
3.6 Every citation intending a particular normative text MUST include both document ID and edition, e.g. RFC-AI 9, Edition 1.0. A generic reference to RFC-AI 9 resolves to its currently designated authoritative edition and MUST visibly state the resolved edition and its status.

4. DOCUMENT LIFECYCLE
4.1 States are IDEA (unallocated exploration), DRAFT, PROPOSED, IN REVIEW, APPROVED, ACTIVE, DEPRECATED, SUPERSEDED and WITHDRAWN. NOT ACTIVE / NOT APPROVED MUST always be visible where applicable.
4.2 Only an approved revision backed by recorded authorization may become APPROVED; activation is a separate, recorded decision. A system MUST NOT infer approval from a filename, packet, timestamp, AI assertion, or published web page.
4.3 A proposal requires named owner, scope, evidence, known risks, affected standards, compatibility analysis, review trail, and disposition of Devil's Advocate findings.
4.4 The CEO holds final release authority unless an explicit, verifiable delegation names the approving role and scope. Automated workers MAY draft, review and test, but MUST NOT self-approve.
4.5 Approval records MUST bind approver identity, UTC timestamp, exact source digest, edition number, decision, and published artifact digest. Withdrawal and supersession require similar evidence.
4.6 Draft expiry or editorial inactivity does not erase identity or history.

5. CHANGES, CORRECTIONS, AND SUPERSESSION
5.1 An EDITORIAL FIX corrects presentation without changing normative meaning; it produces a tracked correction record or new approved edition according to the publication policy, never silent replacement of a locked edition.
5.2 An ERRATUM identifies a defect in a published edition and its verified disposition; it MUST link to that edition and MUST NOT rewrite immutable source evidence.
5.3 An UPDATE modifies or extends a still-relevant standard and MUST explicitly list affected requirements, compatibility and applicability. A SUPERSEDES relationship replaces the prior document's authority, with a precise mapping to the new standard.
5.4 Changes that replace a document's subject, split it, or make citation meaning ambiguous SHOULD receive a NEW RFC-AI number and explicit relationship links; substantial changes within one stable subject MAY use a new major edition if reviewers approve that continuity.
5.5 Multiple publications MAY implement a long-lived policy family, but no second numbering series is introduced unless separately approved. References MUST identify the controlling RFC-AI edition.

6. SOURCE, FORMATS, AND READER
6.1 The controlled, authoritative source is the approved RFC-AI UTF-8 text artifact, with the project's required CRLF line endings and a validated, canonical metadata packet. Each publication has one authoritative source revision and one SHA-256 content digest.
6.2 HTML, PDF, accessibility renderings, search indexes and Reader presentations are DERIVATIVE representations; they MUST identify their source digest and edition. If a rendering disagrees with the source, the source controls until a formal correction is approved.
6.3 The metadata packet and Reader MUST recognize the canonical short RFC-AI identity and draft/edition labels; they MUST NOT require or display the previous padded numbering format as an active identity.
6.4 Source revisions and derivatives MUST be reproducible or otherwise verifiably bound to an archived source digest. Validation MUST detect malformed metadata, integrity failure, unknown identity, and status/approval mismatches.
6.5 The packet format change is itself an interface migration. Readers MUST be updated and tested alongside sources, not after them. A failed migration MUST leave the last working published system intact without presenting mixed active formats.
6.6 Accessibility, internationalization, stable URLs and complete plain-text access are publication acceptance criteria, not optional decoration.

7. REGISTRY, CITATIONS AND HISTORY
7.1 A single authoritative registry MUST store RFC-AI N, subject/title, current draft or edition, lifecycle state, controller, approval evidence, content digest, source location, relations, and UTC event timestamps.
7.2 Registry changes MUST be atomic, auditable, and attributable to an identified actor. Concurrent number requests MUST not allocate the same number. No field or state may be fabricated when unknown.
7.3 Editorial activity is append-only, UTC millisecond timestamped, with deterministic tie ordering. AI workers review continuity newest-first, with older authorized history accessible without artificial lookback restrictions.
7.4 Active catalogs, websites, APIs, Reader results and exported archives MUST resolve the SAME identity, edition, authority and digest. Search results for drafts MUST conspicuously show they are drafts.
7.5 Publication/approval evidence MUST be retained without exposing secrets or private information. Public artifacts MUST not accidentally include credentials, sensitive internal notes, or private review information.

8. GOVERNANCE AND STREAM RESPONSIBILITIES
8.1 RFC-AI is a Peostectica publication stream, not an IETF RFC stream. Its governance MAY learn from the distinction between policy-making, approval and editorial production used in the RFC Editor model.
8.2 Policy authors draft; reviewers and Devil's Advocates examine; the authorized approver decides; the production role publishes EXACTLY the approved digest and verifies public delivery. No stage may silently assume the previous stage succeeded.
8.3 Human authority and AI delegated authority MUST remain distinguishable. Delegation MUST state capabilities and expiry/revocation conditions, and MUST be checked at the approval operation.
8.4 Policies may evolve, but amendments to this RFC-AI MUST follow their own duly approved change path; this draft is not self-ratifying.

9. REQUIRED MIGRATION OF THE INITIAL SERIES
9.1 The active eight original documents MUST receive canonical names RFC-AI 1.txt through RFC-AI 8.txt, with packet IDs, normative references, internal filenames, human citations, and reader output reconciled. The new standard is RFC-AI 9.txt.
9.2 Rewrite active source and reference metadata consistently, normalize CRLF and UTF-8, recalculate digests, and preserve original approval status. A draft remains a draft. No old numbering artifacts may remain as alternate ACTIVE documents.
9.3 Historical backups needed for rollback or evidentiary retention MUST remain outside the active catalog and ordinary user navigation; they are not competing authoritative editions.
9.4 Migrate documents, Registry, Reader, API parsing, navigation, sitemap, cross-references, download packages and live website as ONE compatibility release with tests. Verify all references and byte digests before switching public pointers.
9.5 Never claim migration complete until direct reads prove that both the authoritative connected documents and publicly served artifacts use the new standard. On failure, report the exact incomplete component and preserve last known good service.

10. REQUIRED ACCEPTANCE CHECKS
10.1 Test unique canonical allocation; malformed numbers; conflicts; cancelled drafts; approved-edition immutability; edition increment logic; digest validation; and independent authority verification.
10.2 Test all cross-references, external links, canonical URLs, downloads, Reader functionality, HTTP delivery, UTF-8/CRLF integrity, accessibility, and status labeling.
10.3 Test that no old padded identifiers remain in active registry entries, documents, rendered pages, scripts or downloaded packages. Do not use a successful unit test as a substitute for production readback.
10.4 Perform Devil's Advocate review to completion. Findings are FIXED, NOT APPLICABLE with reasons, or BLOCKED with prerequisites. Only authorized approval enables publication.

11. SOURCE ALIGNMENT AND DIFFERENCES
11.1 RFC 2026 supplies guidance on publication stages, process, document classes and approval; its process has been revised by later RFCs and is not copied wholesale.
11.2 RFC 5741 described provenance and standard headers and was obsoleted by RFC 7841, which should be consulted for the more recent stream/boilerplate model.
11.3 RFC 9720 explains definitive source versus rendered publication formats, and updates the RFC 9280 stability policy; it was subsequently updated by RFC 9920.
11.4 RFC 9280 described separation of policy development, approval and production responsibilities; RFC 9920 obsoletes it and is the current reference for that model at drafting time.
11.5 RFC 2119 and RFC 8174 define interpretive meaning of uppercase requirements keywords.
11.6 RFC-AI's sequential short numbering, draft/edition syntax, single source text format and CEO approval structure are project design decisions. They MUST NOT be misrepresented as requirements imposed by those IETF publications.

12. REFERENCES
[1] RFC 2026, The Internet Standards Process -- Revision 3. https://www.rfc-editor.org/rfc/rfc2026
[2] RFC 5741, RFC Streams, Headers, and Boilerplates (obsoleted by RFC 7841). https://www.rfc-editor.org/rfc/rfc5741
[3] RFC 7841, RFC Streams, Headers, and Boilerplates. https://www.rfc-editor.org/rfc/rfc7841
[4] RFC 9720, RFC Formats and Versions. https://www.rfc-editor.org/rfc/rfc9720
[5] RFC 9280, RFC Editor Model (Version 3) (obsoleted by RFC 9920). https://www.rfc-editor.org/rfc/rfc9280
[6] RFC 9920, RFC Editor Model (Version 3). https://www.rfc-editor.org/rfc/rfc9920
[7] RFC 2119, Key words for use in RFCs to Indicate Requirement Levels. https://www.rfc-editor.org/rfc/rfc2119
[8] RFC 8174, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. https://www.rfc-editor.org/rfc/rfc8174

END OF RFC-AI 9 — DRAFT 1