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

RFC-AI 2 — DOCUMENT LIFECYCLE AND GOVERNANCE
STATUS: DRAFT — CEO APPROVAL PENDING
VERSION: Draft 1 | 2026-10-26 | AUTHOR: FOUNDER

0 PURPOSE
Preserve lessons, not obsolete instructions. This document proposes lifecycle governance for AI standards without burdening workers with competing active paths.

1 NUMBERING
1.1 Allocate new RFC-AI identifiers sequentially: RFC-AI 1, RFC-AI 2, RFC-AI 3, and so on; use short consecutive numbers without gaps.
1.2 Allocate the next sequential RFC-AI number for each new independently governed standard. Appendices, corrections and new editions retain their parent RFC-AI number. Use Draft N for unpublished editorial revisions and Edition major.minor for approved releases; preserve source revisions separately for historical audit.
1.3 Every identifier is immutable and never recycled. Keep a single allocation registry and one active canonical version per subject.
1.4 Links should show exact RFC ID, revision, approval state, and replaces/updates relations.

2 GOVERNANCE STATES
2.1 IDEA: informal exploration with no RFC authority.
2.2 DRAFT: identified content offered for feedback without operational authority.
2.3 PROPOSED: submitted for formal review with an assigned owner, risks and review date.
2.4 IN-REVIEW: objections, alternatives, impacts, international accessibility and evidence considered.
2.5 APPROVED: exact revision accepted by CEO or authorized delegate, backed by independent approval evidence.
2.6 ACTIVE: approved content published in current navigation; approved status in a packet is only a claim, not proof.
2.7 DEPRECATED: supported temporarily while the approved replacement is deployed with an explicit sunset.
2.8 SUPERSEDED: replaced and no longer current.
2.9 WITHDRAWN: abandoned before approval.
2.10 EXPIRED: draft or experimental permission passed its review deadline; does not mean approved standards automatically lose force.
2.11 RETIRED: old operational path safely removed, with required lessons retained in nonoperational evidence.

3 REVIEW REQUIREMENTS
3.1 Every proposal should state the real release objective, scope, implicit professional requirements, affected users, international implications, risks, dependencies, and acceptance evidence.
3.2 Reviewers must assess whether clarifying an existing RFC would be better than adding another. Complexity has a cost.
3.3 Separate authorship, critical review, and approval wherever feasible. CEO or delegated authority remains responsible for final adoption.
3.4 Record substantial disagreements and why decisions were made without publishing two contradictory active policies.
3.5 Verify a new worker can understand the current direction without old chat context. Confusion is a leadership framework defect.

4 AGE AND EXPIRATION
4.1 Drafts should have an explicit next-review date. Initial suggestion: 180 days; passing the date triggers review or expiration of draft eligibility, never automatic approval.
4.2 Active RFCs should get risk-based periodic assessment, initially annually, plus event-driven assessment when technology, security, user needs or law materially changes.
4.3 Age alone does not invalidate a good standard. Reaffirmation can maintain the current version with logged review evidence.
4.4 A deprecated standard must identify the replacement, dependency migration, owner, deadline, acceptance proof and safe retirement plan.

5 REVISIONS, ERRATA AND PUBLICATION
5.1 Classify errata as editorial or substantive. Proposed errata do not silently rewrite normative meaning.
5.2 Editorial reissues should maintain meaning and record exact changes. Substantive policy changes require fresh review and approval and visible dependency analysis.
5.3 Historical published editions should be discoverable as evidence, not runnable or recommended alternatives.
5.4 RFC-AI Reader should display current status, verified approval, original date, revision, supersession and errata links separately from self-declared metadata.
5.5 Keep source documents ordinary UTF-8 CRLF .txt files; themes and HTML display are derived presentation, not competing source authority.

6 RELEASE ACCEPTANCE
The current approved document must be found from Framework/readme.txt. A new worker can tell draft from active, understand why it applies, locate updates, and avoid obsolete procedures. Validate the actual worker experience, then troubleshoot from RELEASE DOWN using WWWWH.

7 RESEARCH BASIS AND LESSONS
The IETF differentiates drafts, published RFCs, errata, Updates, and Obsoletes relationships. RFC 9720 separates definitive content from publication versions. RFC 9920 (2026) updates the editorial governance model and discusses preserving meaning in reissues. Historical pain points include complex publication tooling, stale cross-references, obscure status/errata, accessibility, and balancing archival stability with corrections. These are research-supported problem categories, not a statistical ranking of worldwide complaints.
https://www.rfc-editor.org/rfc/rfc9920.html
https://www.rfc-editor.org/rfc/rfc9720.html
https://www.ietf.org/process/rfcs/

8 APPROVAL
DRAFT only. CEO review pending. No company-wide activation.

9 CHANGES AND CROSS REFERENCES
9.1 Version 0.2.0 places the required human reader notice as the second physical line after the packet. The next line is blank. Rendering may hide this preface; raw mode MUST expose it. The packet checksum includes this notice.
9.2 The purpose and deeper guiding-principle rationale are proposed in RFC-AI 3. This lifecycle RFC must not turn reflective guidance into an automatic approval or allow adopted corporate obligations to become optional.
9.3 This RFC remains a CEO-review draft; it does not authorize standards adoption.

MIGRATION RECORD — 2026-10-29 UTC