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

RFC-AI 26 — STANDARDS REGISTRY, DRAFT AUTHORITY AND CONFORMANCE
DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE
STATUS: DRAFT FOR CEO REVIEW — ENTIRE RFC-AI SYSTEM UNIMPLEMENTED

1. PURPOSE — WHAT AND WHY
Keep a clear, meaningful, authoritative RFC-AI catalog. The RFC-AI series includes two distinguishable document purposes: guiding AI RFCs, which direct intelligent judgment, and Standards, which contain precise technical requirements within their stated scope.

2. INTELLIGENT-WORK DIRECTION
Classify by actual document contents. Keep one stable authoritative document identity and clear approved/draft status. Allow Interfaces and implementers to own HOW unless a Standard specifies it. Do not confuse an old system or a draft with an implementation of these RFCs.

3. PROPOSED IMPLEMENTATION APPROACH
Use the relevant authorized Interface, component and expressly designated Standard: RFC-AI 2, 9, 3 and the standards registry. Investigate the complete relevant context before deciding what the assignment means (see RFC-AI 11). A competent worker may discover, invent and improve the necessary methods during implementation; this guiding AI RFC is not required to repeat low-level APIs, algorithms or technology choices. Previous and legacy systems are research evidence only, never an implementation of this draft.

4. EVALUATION AND ACCOUNTABILITY
Use independent DAVG as described in RFC-AI 22 to challenge whether the eventual real-world result meets the objective, not whether the AI RFC looks like a traditional API specification. A missing prerequisite creates an active cross-worker recovery obligation through the worker coordination Interface, not a reason to abandon the task (RFC-AI 20 and 31). Report only verified effects and preserve lessons without reintroducing old operational mistakes.

5. DESIGN CUSTODY
Original subject-specific intended contract: Our drafted RFC-AIs are the designated design authority, distinct from CEO approved operational policy; numeric registry, conflicts, compatible changes, traceability from RFC to code and tested deployment; reconcile RFC-AI 9.
Implementation tasks, legacy-derived candidate methods, proposed data schemas, tests and open engineering questions are kept with this draft's append-only objectives.txt or the responsible Interface/Standard. This RFC has NOT been implemented; it does not approve a deployment or create a new CEO release gate. Rewritten 2026-11-02T20:28:09.285Z.


## HISTORICAL FAILURE EVIDENCE — RESEARCH ONLY; NOT AN RFC-AI IMPLEMENTATION
Historical context: Legacy instructions and provisional drafts were sometimes rediscovered as though binding current guidance; Standards and AI RFCs were confused.
Historical reports have mixed evidence quality; verify primary facts before adopting a claimed root cause. Preserve source provenance and do NOT operationalize retired legacy policies as current RFC authority.

## MUST-DESIGN CRITERIA — CEO-DIRECTED PROPOSED FUTURE SYSTEM
MUST-26-01: MUST identify an RFC as guiding AI RFC or detailed Standard based on its actual nature and declared purpose, not a traditional-RFC expectation or numbering.
MUST-26-02: MUST provide definitive current/source/retirement mapping for every RFC and separate deployment/authority state from document readiness.
MUST-26-03: MUST NOT migrate historical system behaviors into new RFC normative obligations without explicit new reasoning and authorization.

IMPLEMENTATION STATUS: Entire RFC-AI system NOT IMPLEMENTED. Historical systems are independent past research material; no test or existing service may be counted as implementing this RFC-AI.


## ADDITIONAL MUST-DESIGN CRITERIA — 2026-11-02 (PROPOSED, NOT IMPLEMENTED)
Historical trigger: legacy materials repeatedly confused authored progress, scripts and document content with real observed execution; this is research evidence, not proof of any new RFC implementation.
MUST: Specify which AI RFC/Standard version applies to assignment and Interface pieces; document compatible transitions without demanding every guiding AI RFC specify implementation internals.
MUST consider the concrete literal behavior of competent AI workers and enforce required hard safeguards by simple, separately running Interface logic where an actual boundary exists. MUST not delegate Interface internal details back to this guiding document. MUST preserve the requirement in relevant top-level objectives.txt and independently verify that future implementation satisfies it. New requirements here remain draft, not live controls.

## DESIGN AMENDMENT 2026-11-03 — CONTRACT REGISTRY
REQ-AI-26-REG-001: Every guiding AI RFC and Standard MUST have stable numeric identity, explicit document class, actual canonical source ID/revision/digest and a single active registry entry per governing edition; preserve historical editions as non-current research evidence.
REQ-AI-26-REG-002: Normative MUST/MUST NOT text MUST remain in each RFC. The requirements ledger is a derived locator and MUST map obligation ID to the correct Standard/Interface, independent test oracle and evidence scope; the ledger cannot replace the RFC. Conflicting public/Drive derivatives MUST be flagged until reconciled.

DESIGN CORRECTION INTEGRITY-19 — Source trust, non-circular digests and requirement edition mapping
RATIONALE: A SHA field inside its own hashed payload is circular, while a self-consistent packet hash says nothing about which draft is authoritative or approved.
REQUIRED FUTURE BEHAVIOR: The document integrity contract MUST specify exact byte range and external digest custody. A recognized first-CRLF packet digest covers only bytes after that delimiter. For a JSON contact document, digest MUST be stored outside its hashed payload in authenticated SourceRegistry or a nonhashed preamble; no self-referential digest is normative. Every published RFC edition MUST map stable requirement IDs to an actual governing source revision, accountable Standard/Interface, positive and negative tests and independent evidence. Unsupported metadata is UNVERIFIED, not INVALID; a verified wrong known digest is FAIL.
ADVERSARIAL DESIGN ACCEPTANCE: Alter the body without changing the conventional preamble: digest fails. Change an external authority record: signed governing edition fails or conflicts. Verify unknown JSON metadata is inert, distinct from source approval. Reject claims that a checksum makes an unapproved draft policy.
SCOPE: Proposed requirement and acceptance test, NOT actual implementation or verified enforcement.