#!RFC-AI/2;id=34;draft=9;v=0.8.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=044f4ce6624cde532ba02508af713043439a637b1d331c870a4e4d7af0383eaa For easier reading, view RFC-AI documents using RFC-AI Reader software. RFC-AI 34 — FRAMEWORK RECORD SEPARATION, INTUITIVE NAMES, SOURCE CUSTODY STATUS: DRAFT 9 — CEO REVIEW REQUIRED; NOT ACTIVE; NO FOLDER MIGRATION AUTHORIZED DATE: 2026-11-02 UTC | ID PROVISIONAL under RFC-AI 9 RELATED: RFC-AI 3,4,5,6,7,8,9,28,31,32,33,35,36. ABSTRACT Maintain separate authoritative records for principles, worker identity, roles, training, tasks, worker continuity, machine inventory, runtime context, human instructions, research and system evidence. Humans navigate ordinary stable names. The framework assembles one per-worker contact view, but that view never replaces source evidence or grants permissions. Only simple fixed software logic selects and joins these records. 1. REQUIRED SEPARATION AND OWNERSHIP 1.1 Logical record classes: SHARED_GUIDANCE; FRAMEWORK_RFC; WORKER_IDENTITY; NICKNAME_RESERVATIONS; ROLE; TRAINING_CURRICULUM; WORKER_TRAINING_EVIDENCE; TASK_ASSIGNMENT; WORKER_CONTINUITY; MACHINE_INVENTORY; LIVE_CONTEXT; HUMAN_DIRECTIVES; RESEARCH_RECEIPTS; FORENSIC_EVENTS; POLICY_DECISIONS; EXECUTION_RECEIPTS. A single giant employee JSON, an AI-generated summary or hidden chat memory MUST NOT become their shared authority. 1.2 The organization's existing private canonical Google Drive is the source of framework documents in this installation. The exact provider file ID/revision controls; operating-system copies are executable/config/runtime only. Preserve one canonical source per class; no staging, duplicate folder tree or unapproved alternate source. 1.3 Generic framework templates MUST be separated from owner-private instructions, account identity, permissions and worker histories. An assembled contact document is a derived view only, not an independently edited source. 1.4 Class-specific data owners: CEO/authorized policy editor for guidance and directives; authenticated identity registrar for worker tuples/nicknames; designated role/training owners for curricula; assigned work authority for task obligations; system collectors for independent evidence; verified machine administrator for machine inventory. An AI's record assertion cannot confer authority. 2. INTUITIVE PHYSICAL NAMES (DESIGN MAPPING, NOT CREATED FOLDERS) 2.1 Stable familiar labels: Framework, Workers, Roles, Training, Assignments, Continuity, Machines, Research, Evidence. Keep existing source names if already established; reconcile duplicate historical trees before changing anything. The following paths describe the desired *logical arrangement*, relative to the approved private root: Corporation/Framework/AI_RFC/RFC-AI N.txt governed RFC source (already present) Guiding_Principles.md existing top-level shared-principles entry Workers//identity.json private four-field identity record Workers//Continuity/ chronological private handoffs Workers/Roles// role requirements and specialized context Workers/Training// versioned training curriculum and evaluations Workers/Assignments// durable assignment and task checkpoint Machines// machine inventory and capability records Corporation/Framework/Research/ independent receipt catalog / safe references Corporation/Framework/Evidence/ protected forensic and policy-decision catalog The actual registered provider file IDs, ACLs and existing canonical folders MUST be resolved before selecting locations. Existing Peostectica/ContinuityVault, Corporation/ContinuityVault, Workers/Roles and Google Drive Machines are historical inputs to reconciliation, not automatically abandoned or copied. 2.2 Files for stable concepts have predictable unsuffixed names (identity.json, objectives.txt, readme.txt, role.md, training.md, task.json, inventory.json, mandated.md, forbidden.md, checklist.md, da.md). Company naming may use .txt where already authoritative; do not rename merely to impose an extension. Every non-objectives corporate artifact retains its existing required paired objectives document unless a later approved exception applies. 2.3 Dated records have fixed-width UTC-millisecond-leading names and short intelligible descriptors, newest-first lexical order: example 20261102T153000000Z-Alex-activity.txt. RFC-AI 6 governs any additionally required monotonic counter/UUIDv7 for that RECORD class; UUIDv7 is NOT imposed as worker ID. Actual observed UTC and logical issue order must be distinguishable. Safe ASCII path labels only, collision checks, no traversal or arbitrary system-derived paths. 2.4 Names help humans browse but grant no rights. Provider file identity/revision and registry tuple govern exact reference. Nickname rename preserves history and never grants old documents to an unrelated worker. 3. SOURCE CATALOG, LINKS, VERSIONS AND TRANSACTIONS 3.1 Each class has a single authoritative catalog entry with: class; provider resource ID; current version/digest; human-readable path; access classification; permitted editor; owner; UTC observation; source provenance; retention and supersession link. Catalog itself must be protected and read back after writes. 3.2 Joins worker→role, worker→tasks, worker→training, task→machine and task→evidence use exact identity/assignment references, never AI inference from filenames or semantic similarity. Missing, duplicate, inaccessible or conflicting sources produce explicit error/coverage reports, not fabricated fallback records. 3.3 Changes require authenticated authority, expected revision and atomic or serialized update; retry and recovery use idempotency keys. Concurrent registration, role changes and source deletion must not yield multiple authoritative answers. Preserve older revisions and migration provenance according to existing approved preservation requirements. 3.4 Historic approved RFC edition bytes cannot be overwritten; update drafts or publish a new edition under RFC-AI 9. All material changes identify changed semantics, affected interface readers, migration, rollback, negative tests and resulting source revision. 4. CLASS-SPECIFIC DATA CONTRACTS 4.1 SHARED_GUIDANCE holds durable organization-wide principles, not short-lived website work or confidential Alex-specific details. Human directives remain signed/authenticated records separate from generated worker views. 4.2 WORKER_IDENTITY holds type+provider+selector+account as composite ID; nickname unique alternative index, optional providerUID for future verification; private storage. Pre-onboarding nickname reservations are distinct from authenticated worker records. See RFC-AI 33. 4.3 ROLE and TRAINING hold current role mandates and curriculum, separate from worker performance/evidence. A worker may hold multiple authorized roles. Required training may be embedded by reference in a contact view, but does not itself grant privileged tools. 4.4 TASK_ASSIGNMENT holds durable objective, human origin, assigned tuple, task status derived from actual records, last verified result, dependencies, next action, and recovery pointer. OPEN obligations remain accessible regardless of event age or truncation. Worker handoffs are separate chronological records. 4.5 MACHINE_INVENTORY stores relatively stable managed-machine facts; LIVE_CONTEXT records expiring observations of human session device, worker execution host, target host, connection health and permissions. Never persist transient 'online' as durable truth. 4.6 RESEARCH_RECEIPTS, FORENSIC_EVENTS, POLICY_DECISIONS and EXECUTION_RECEIPTS are separate from worker narrative. Include source, revision, correlation, observed/received UTC, confidence/verification status and privacy limits. Do not treat citations or self-reported tool reads as independent observation. 5. CLASSIFICATION, RETENTION, PRIVACY 5.1 Shared public RFC text MUST use synthetic identities. Real account identifiers, worker-private continuity, CEO memory, OAuth secrets, credentials and private audit details remain restricted. Scope access by authenticated worker ID, task, role and least privilege; cross-worker reading must be specifically authorized. 5.2 Logs can contain personal data; minimize and redact secrets before cross-worker transmission, retain necessary audit evidence according to approved policy and documented legal constraints. Never hide a gap in instrumentation or missing evidence. Tamper resistance requires controlled independent custody, not merely appending to a worker-editable file. 5.3 Deletes, renames, revisions and access revocations must preserve necessary source pointers and distinguish history from current permissions. Do not destroy unique historical data during cleanup. 6. MANDATORY FOUNDER CHANGE-IMPACT PRACTICE 6.1 Every founder MUST assess changes affecting identity, roles, training, machines, task state, evidence, source classification, document assembly or enforcement for impact on RFC-AI 33–36 and GetWorkerContinuity/GetWorkerContext. Record affected classes, migration/compatibility, tests and DAVG findings. NO_IMPACT requires a justified, checked finding; never assume because a change seems small. 6.2 The framework should automatically require compatible schemas and assembler tests as part of an existing authorized development/check workflow. This is a governance design, not an AI-created CEO release gate. The CEO retains release authority. 7. REQUIRED NEGATIVE TESTS AND RECONCILIATION 7.1 Missing/duplicate files, provider ID mismatch, revised directive, obsolete role, ambiguous email, nickname rename, private-data leakage, disconnected Drive, two writers, stale revision, invalid UTC, malicious log text, old open task and machine switching. 7.2 A human must locate shared principles, worker identity, role curriculum, unfinished task, machine inventory and evidence by readable path without knowing a GUID. Compare actual provider IDs and access independently. 7.3 DAVG unresolved: reconcile physical root placement of legacy ContinuityVault, Workers and Machines; define retention, ACLs, registry source IDs and transaction mechanism before implementation. No folder migration is implemented or authorized here. 8. EXTERNAL RESEARCH AND LIMITS LangGraph persistence separates durable stores and thread checkpoints: https://github.com/langchain-ai/docs/blob/main/src/oss/langgraph/persistence.mdx LangGraph design recommends storing raw state and deriving presentation: https://docs.langchain.com/oss/javascript/langgraph/thinking-in-langgraph Temporal event history separates actual workflow evidence from summaries: https://docs.temporal.io/encyclopedia/event-history JSON Schema validates structure but not identity/permissions: https://json-schema.org/specification NIST SP 800-53 addresses provenance, audit, least privilege and log privacy: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final Design only; no provider/mount or full enforcement equivalence is presumed. DAVG DESIGN CORRECTION — 2026-11-02 UTC (DRAFT; SEE RFC-AI 37) Add separate classes for optional "working-mode" routing and PROVIDER_PROFILE (non-secret general provider+type+selector observations) and ACCOUNT_CAPABILITIES (private account/mode-specific entitlements), with logically proposed names Corporation/Framework/Providers//profile.json and authorized private Workers//provider-capabilities.json. Existing canonical Drive folders and ACLs take priority until explicitly reconciled: these are design patterns, NOT automatic directory creation. RFC-AI 37 controls refresh; allow only ephemeral in-memory cache, not a second filesystem master. Source catalog records successful refresh, expiry, revision/digest, source API/document, uncertainty and provider deprecation. Do not mix the 6h profile freshness state with RFC-AI 8 clock sync. Every founder changing these schemas must update RFC-AI 33/35/36/37 adapter and acceptance checks. 9. DAVG PROVIDER-INDEPENDENT VERIFIED SAVE RECEIPTS AND SOURCE CATALOG — 2026-11-02 UTC (DRAFT) 9.1 The source catalog MUST track verified stored content per exact canonical file ID and revision, not a mutable alias/path alone. Source checksum means the bytes of a Drive-stored file as committed, not a cached rclone/FUSE buffer. Record client SHA-256 of exact upload bytes, provider-returned independent algorithm/digest when supplied, file ID/parent/revision and UTC. Evidence receipt and historical versions reside separately from the canonical file and cannot become competing active files. 9.2 RFC-AI 38 defines one save call returning a validated provider receipt; do not store a client-supplied digest as if provider calculated it. If the repository is a native editor format or lacks a comparable checksum, return unverified until provider-supported targeted validation succeeds. Hash mismatch or missing evidence is not permission to blindly rewrite the file. 9.3 Newly updated files should not trigger listing/downloading the entire parent directory. Cache freshness and exact file identities with explicit invalidation on conflicting revisions, moved files and true errors; prefer batch requests and return the verification status to the invoking worker. Maintain a short operation-cost and escalation receipt; avoid a database of speculative worker status. CEO VERIFIED-SAVE ACKNOWLEDGMENT LADDER — 2026-11-02 UTC (DRAFT ONLY) RFC-AI 38 now defines one ordered storage-interface response: (1) independently received expected byte count and SHA-256, (2) authoritative provider commit, (3) correct file ID and destination, (4) independently stored content checksum, (5) correct revision and authorized operation. Short-circuit failed/unknown checks and retry only when safe; ambiguous commits require reconciliation. Do not send repetitive full reads after a VERIFIED receipt. This is a proposed interface contract, not evidence of implementation. DOCUMENT CLASSIFICATION — RFC-AI RESEARCH-FIRST RECONCILIATION (2026-11-02T20:28:09.285Z) DOCUMENT CLASS: STANDARD — TECHNICAL STANDARD DRAFT This document contains normative technical format, protocol, security, interface, or evidence contract detail for its defined subject. The detail is an intended Standard rather than evidence that software has been built or deployed. Legacy software and its records are background research only; no RFC-AI component is implemented. DAVG judges future objectives and observed results, rather than presuming legacy implementation or declaring these drafts active. CEO approval and independently observed operational evidence are still required for any future activation. ## HISTORICAL FAILURE EVIDENCE — RESEARCH ONLY; NOT AN RFC-AI IMPLEMENTATION Historical context: Duplicate cloud roots, stale derived files and active/archived document mixing reintroduced superseded guidance. 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-34-UTC: Any current UTC datetime, timestamp, deadline, source-freshness comparison, expiry, or chronological identifier MUST obtain current time through GetUTCDateNow() or its approved typed Time Interface result. AI workers and application code MUST NOT read a host local clock directly for corporate decisions. The Time Interface owns actual synchronization, drift detection, freshness evidence and explicit uncertain-clock handling; a stored expiration alone never proves clock correctness. This is a future design obligation, not an implemented service. MUST-34-01: MUST label source retirement explicitly and immediately remove retired content from active instructions, registries, search, derived copies and worker assembly once verified unused. MUST-34-02: MUST thoroughly delete truly obsolete material after validated dependencies, authorization and applicable retention requirements; do not leave abandoned duplicates or false authority in active pathways. MUST-34-03: MUST reject two distinct canonical roots for the same document and verify deletion/cleanup from actual destination. 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: Keep forensic observed records in separately controlled provenance from AI-written DATA/METADATA. All context assembly must use exact source IDs and trust classes; no inference that a text file is an actual execution event. 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 — THREE DISTINCT RECORD CLASSES REQ-AI-34-CLASS-001: Worker identity/continuity, real operating context and authenticated task assignment are THREE SEPARATE SOURCE RECORD CLASSES, not three worker documents. The future assembler MUST output exactly ONE Worker Contact Document with substantive Continuity required and optional useful Context and optional current Assignment in that order. Training/competence is an optional nested subsection. Source records remain separate for ownership, custody and permissions. REQ-AI-34-CLASS-002: Workers/Machines and actual execution host, human user device and task target MUST have distinct typed IDs. Current context contains organization location, governing edition, runtime, tools, OS and environment, independent source/UTC/freshness/UNKNOWN. Assignment MUST be LAST and bind objective/revision/epoch/pieces and target overlay without rewriting context. REQ-AI-34-SOURCE-003: Retired historical policy MUST remain retrievable as research with explicit noncurrent authority, but no stale copy may silently supply current instructions. Exact IDs, permission visibility and verified derivative cleanup are required; do not mirror every same-named Drive folder as a supposed authority fix. DESIGN CORRECTION CATALOG-16 — Retired sources, migrated roots, contacts and catalog identity RATIONALE: Drive duplicate folder names, GPTChat-to-Peostectica migration and stale cached instructions make a directory or search result an unreliable source of current policy. REQUIRED FUTURE BEHAVIOR: A future source catalog MUST distinguish canonical active ID, archived predecessor, preserved rollback, derived Reader/web copy and unauthorized shadow copy. A root migration MUST record old/new exact IDs, authoritative cutover time, ACL revision, dependency references, preserved evidence, cache invalidation plan, discovery index completion and independent CEO-visible readback. Historical lessons remain queryable as historical research; retired instructions MUST NOT regain active authority through a search rank or cached context. Contact records for support/recovery MUST remain independently recoverable even if primary website identity is deleted. ADVERSARIAL DESIGN ACCEPTANCE: Create two same-named Drive folders and a stale former GPTChat instruction. After explicit cutover, only one authenticated current ID may govern; cache/client lookup returns CONFLICT or retired history rather than activating obsolete policy. Simulate loss of the primary website contact directory. SCOPE: Proposed requirement and acceptance test, NOT actual implementation or verified enforcement.