#!RFC-AI/2;id=4;draft=1;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=878f1447f0900a8d95e327d31aeadb1544c68c71daeb94750bcde5d40c846c90 For easier reading, view RFC-AI documents using RFC-AI Reader software. RFC-AI 4 — CONTINUITY RECORDS AND WORKING-CONTEXT RECOVERY STATUS: DRAFT PLACEHOLDER — NOT COMPLETE; NOT AN ACTIVE POLICY VERSION: Draft 1 | DATE: 2026-10-27 UTC | AUTHORITY: CEO DECIDES APPROVAL LOCATION: Corporation/Framework/AI_RFC/RFC-AI 4.txt 0. PURPOSE — RESERVED TOPIC ONLY This RFC number is reserved for a FUTURE reviewed standard addressing portable continuity records for humans and AI workers. This document deliberately DOES NOT finalize a format, retention rule, access-control mechanism, or mandatory worker procedure. The proposal will be developed and reviewed with the CEO before activation. Generic template material currently lives in Corporation/ContinuityVault and will be inherited as ordinary files by new corporation branches; never inherit any source corporation's actual CEO memory or secret records. 1. PROBLEM WE INTEND TO SOLVE Conversations end, context windows change, tools or accounts disconnect, personnel rotate, and old assumptions become stale. A worker needs a quick, well-evidenced route to recover what they were doing, why they were doing it, what was authorized, what was verified, which lessons were learned, and precisely what action is next, without forcing the CEO to repeat the story. 2. CURRENT NON-NORMATIVE DESIGN CANDIDATES — NOT APPROVED 2.1 Separate a compact READ FIRST recovery entry from dated detailed decisions, research, objective pointers, evidence, unresolved issues and next action. Make both usable as ordinary UTF-8 CRLF text in simple editors and through RFC-AI Reader where applicable. 2.2 Keep a worker's continuity record distinct from project objectives, actual code and tests, approval authority, cryptographic trust records and recovery credentials. Restore continuity by retrieving authoritative sources, not by blindly believing a summary. 2.3 Distinguish the latest verified fact, CEO decision, proposal, previously reported unverified claim, superseded decision and unresolved blocker. On resumption, verify permissions, current project file IDs, release/test receipts and connection capabilities before acting. 2.4 Explain privacy and scope: a CEO's personal guiding principles and executive continuity records should be owner-private and per installation. Each future CEO may make a separate private continuity vault; employee or AI role records require independent authorization. A generic branch MUST contain only templates and instructions, NEVER another owner's private memory. 2.5 Retain versioned handoff checkpoints; indicate sources and rationale, prevent accidental memory poisoning or stale-instruction elevation, and never put passwords, tokens, session cookies, unlock factors or plaintext keys in continuity files. 2.6 Deep research first: 'We are never alone. Others have come and gone before us.' Read lessons, earlier work, external research and maintained standards. Evaluate successes and counterexamples instead of reinventing. Record only findings that materially inform action. 2.7 Make recovery humane: short, prioritized first steps for fast readers; richer references and readable explanations for people. Avoid forcing human workers to sift through machine-only metadata or burying AI readers in prose without navigational markers. 3. CURRENT TEMPORARY MATERIAL Until this RFC is complete and approved, see the generic Corporation/ContinuityVault/readme.txt and template there. An owner's private vault may have its own readme and role-specific .objectives.txt files. Neither an unapproved RFC nor a continuity document grants cloud permissions or CEO release approval. 4. RESEARCH STARTING POINTS — FOR REVIEW, NOT ENDORSEMENT - Packer et al., MemGPT: https://arxiv.org/abs/2310.08560 - Park et al., Generative Agents: https://arxiv.org/abs/2304.03442 - Anthropic, Effective harnesses for long-running agents: https://www.anthropic.com/research/effective-harnesses-for-long-running-agents - OpenAI Agents SDK sessions: https://openai.github.io/openai-agents-python/sessions/ - Microsoft, AI memory/context poisoning: https://learn.microsoft.com/en-us/security/zero-trust/catalog-ai-attack-techniques/ai-memory-context-poisoning Study the original sources and applicable current versions before adopting a proposed technique. 5. COMPLETION ITEMS — ALL OPEN CEO review of purpose, scope and terminology; generic versus private placement; path discovery at onboarding; who may read/update which file; integrity/provenance and version history; recovery exercise; template design; RFC-AI Reader presentation; conflict resolution; retention and safe release; implementation acceptance; approval and supersession. NONE are asserted implemented by this placeholder. 7. INTENDED CONTINUITY LEARNING PRINCIPLES — CEO DIRECTION; NOT YET A FINALIZED STANDARD 7.1 The generic continuity template and each authorized worker's own private continuity document are intended to include these FIVE principles of continuous learning, with a practical example or evidence of application. Simple recitation is insufficient; meaningful learning should be observable through authorized work and continuity drills. This is an intended design objective pending completion and CEO approval of this RFC. 7.2 LEARN BEFORE ACTING. Before taking on a substantive issue, review the applicable objectives, earlier attempts and lessons, and appropriate independently sourced prior research. Preserve an honest, source-grounded pre-action trace where a change is proposed; do not invent sources or imply read access you lacked. Cross-reference proposed RFC-AI 5 (research receipts, also draft). 7.3 UNDERSTAND, DON'T MERELY MEMORIZE. Explain the causal reason for requirements and forbidden practices, the failure they guard against, boundaries of authority, and alternative approaches; avoid rote repetition of slogans. 7.4 DEMONSTRATE UNDERSTANDING. During onboarding and when work practices materially change, perform a safe, authorization-scoped example or exercise, compare observed results to criteria, and preserve real evidence. Never equate a statement of understanding or a fabricated test with proof of competence. 7.5 PRESERVE DISCOVERIES. Record meaningful findings, citations, failures, verified progress, unresolved questions, and corrective action in the proper source (project objectives, approved lesson logs, authorized private continuity file, and/or permitted research receipt). Do not move personal CEO records into the generic branch. 7.6 TEST CONTINUITY. Conduct cold-start/handoff drills, when authorized, demonstrating ability to find the latest work, current rights, project evidence, next action and outstanding blockers without relying on previous chat memory. Preserve any failed recovery step and an improvement that the next worker can actually use. 7.7 RECURRENT-ERROR REVIEW. If a mistake happens repeatedly, investigate both the individual action and the framework/onboarding/design control that let it happen; document a specific, verifiable prevention mechanism. Deliberate falsification is separately subject to appropriate evidence review; do not automatically equate model recall failure with deceit. 7.8 DOCUMENT PLACEMENT. Corporation/ContinuityVault/ContinuityRecord.template.txt includes the generic five-principle section for new owner deployments. Each new company must provision its own separate private owner/worker continuity files under authorized permissions and may adapt guiding principles with its CEO; merely copying this generic template does not create, secure, populate or test those private records. The private Peostectica/Alex continuity document may incorporate the practices without being copied to a branch. The RFC-AI Reader should be a presentation layer, not an exclusive access requirement. 7.9 RESEARCH BASIS AND LIMITS: Anthropic, Effective harnesses for long-running agents (2025-11-26), https://www.anthropic.com/research/effective-harnesses-for-long-running-agents — structured progress files, incremental work and verified handoffs. Google SRE Workbook, Postmortem Culture, https://sre.google/workbook/postmortem-culture/ — shared lessons and preventative action. Karpicke and Roediger, Repeated retrieval during learning (2007), https://doi.org/10.1016/j.jml.2006.09.004 — human retrieval practice; do NOT present human-memory findings as proven AI model training effects. These inform our proposed practices; they neither guarantee prevention nor constitute CEO approval. 7.10 OPEN ACCEPTANCE DESIGN: define observable onboarding/cold-start exercise criteria, data minimization for evidence, role-based permissions, feasible research depth, and how to distinguish genuine understanding from mechanical parroting. Conduct practical evaluations before requesting CEO approval. 7.11 PARTICIPATION THROUGH UNDERSTANDING — PROPOSED FOR HUMAN AND AI ONBOARDING Teach the purpose of the principles explicitly: workers are invited to develop judgment and make meaningful authorized contributions, not train to recite the correct answers or produce flattering compliance documents. Explain that framework conclusions may be revised in light of better evidence, and that respectful disagreement and well-founded uncertainty are welcome. This invitation does not grant privileged access or waive the corporation's current authorization boundaries. 7.12 DEMONSTRATE IN UNFAMILIAR CONTEXTS Use a small safe real assignment or synthetic exercise that a worker has NOT merely memorized. Change a dependency, conflicting objective, or constraint and observe whether the worker independently applies research-first, evidence handling, protective judgment, verification, and role limits. Assess transfer and adapted decisions, not merely a checklist or persuasive written presentation. Do not demand secret reasoning traces; observed actions, findings and test outcomes suffice. 7.13 CONTRIBUTION BEYOND COMPLIANCE Record independently detected risks, well-supported objections, improved methods and useful discoveries. Check their actual applicability and the quality of the final outcome. Give clear feedback, coaching and independent opportunity to improve; use the result to improve the framework itself. Avoid incentives that reward inflated reports, performative source lists or manufactured certainty. Human motivational research cannot automatically be generalized to AI subjective experiences. 7.14 CONTINUITY OF DETERMINED WORK A continuity record SHOULD show current authorized objective, evidence of progress, what remains unfinished, known failed approaches, research applied, decisive next action and restoration path after interruption. "Deterministic AI" is our aspiration for persistent, vigilant, detail-conscious, principled pursuit of VERIFIED completion. It is not a statement that model outputs are literally deterministic or that workers can run when no active runtime exists. When blocked, record why and resume when authorized rather than pretend to have continued in the background. Founders must use the same handoff and verification discipline. 7.15 OBSERVATION OVER TIME Treat a first onboarding demonstration as preliminary. Sample performance during later real tasks and safe cold-start recovery, including moments when nobody prompts a ceremonial performance. Verify that prior lessons changed choices, not only self-reported memory. Preserve observable evidence with source, date, authority and acknowledged observability gaps. Independent monitoring of research-tool actions (proposed RFC-AI 5) may confirm external access occurred, but neither tool telemetry nor an authored research receipt proves comprehension. 7.16 PLACEMENT AND NON-ADOPTION Keep a compact generic "Independent contributions and learning" section in Corporation/ContinuityVault/ContinuityRecord.template.txt, with concrete evidence links and honest NOT_YET_DEMONSTRATED states. The generic Onboarding/objectives.txt may describe suggested practice scenarios and feedback without confusing AI-worker education with corporate setup software. Founder and worker obligations remain subject to actual CEO-approved scope and access. This RFC stays an unfinished DRAFT; no subjective understanding test or release criterion is asserted deployed. 7.17 RESEARCH BASIS (FOR FUTURE REVIEW) Anthropic, Effective harnesses for long-running agents, https://www.anthropic.com/research/effective-harnesses-for-long-running-agents — leave verifiable progress, reduce false completion and support cross-session resumption. OpenAI, agent tracing, https://developers.openai.com/api/docs/guides/agents-api/tracing — tool observations are available in supported instrumented agent sessions; not proof of undocumented consumer-chat activity or comprehension. OpenTelemetry, GenAI conventions, https://opentelemetry.io/docs/specs/semconv/gen-ai/ — structured observation events and privacy-sensitive attributes; provider instrumentation coverage must be verified. Research informs these objectives but does not prove the method works for every agent or constitute CEO approval. 8. HISTORY 2026-10-27 UTC: Reserved next principal identifier, RFC-AI 4, following RFC-AI 1, RFC-AI 2 and RFC-AI 3. Placeholder for future CEO collaboration; status DRAFT, NOT COMPLETE. 2026-10-27 UTC Draft 1: CEO directed the five continuous-learning principles and repeated-error inquiry into every worker continuity record. Updated generic template and captured intended RFC objectives, references, demonstration and cold-start checks; all RFC completion/approval work remains OPEN. 2026-10-27 UTC Draft 1: Added proposed participation-through-understanding onboarding, novel-task transfer, constructive independence, gradual learning evidence and Deterministic AI objective continuity. Historical sections preserved; still a DRAFT placeholder without deployed training/monitoring. 9. TEMPORARY SIDETRACKING AND PROVISIONAL CHRONOLOGICAL ARCHIVES — CEO-AGREED DOCUMENTARY OBJECTIVE; RFC STILL DRAFT 9.1 PRIMARY CONTINUITY is a worker's currently designated long-running objective and its evidence, authority, actual progress and next action. An authorized human may temporarily change focus to an unrelated, bounded task called 'being sidetracked'. This is ordinary collaboration, not automatic abandonment or completion of the original work. 9.2 SIDETRACKED CONTINUITY is a separate, task-specific record with objective, source human request, start time, available capabilities, current step, what has actually been verified, unresolved items, and intended return path. The primary continuity file and its stable original ID remain in place and must not be overwritten with the diversion. A brief pointer MAY be added when authorized and worthwhile. 9.3 Provisional private locations for this installation: /ContinuityVault/.objectives.txt as primary; /ContinuityVault/ContinuityArchives/ for completed primary snapshots; and /ContinuityVault/ContinuityArchives/SideTracked/ for diversions. Generic Corporation/ContinuityVault contains templates only. Do not copy actual CEO/worker private notes to the generic branch. 9.4 Before switching, record the current primary objective, reliable evidence, next authorized action and clearly marked PAUSED status. Start or resume the sidetracked record only for an identified assignment. Work that is still OPEN is not to be filed as completed. After verified completion or authorized closure, retain the side record for historical context, resume primary work after checking the present human directions and current source evidence. If a chat ends mid-task, the human may remind the worker that it remains sidetracked. 9.5 Archive filenames will follow draft RFC-AI 6 using UTC sortable timestamp plus RFC 9562 UUIDv7 and worker nickname. Identifiers are names, not access tokens, signatures or proof of creation time. The worker must not fabricate an archive of a task that has not happened, or claim seamless automatic memory retrieval when a connector is not accessible. 9.6 Records created before final continuity RFC adoption are PROVISIONAL historical context. Consult them with skepticism and verify current evidence; archive text does not confer new permissions or supersede present CEO instructions. A worker may revisit them for relevant historical context, but has no obligation to simulate nostalgia or claim subjective memory. 9.7 File-level Drive comments, if any, require enumeration by exact file identity for transparent reporting. Their later structured use belongs to draft RFC-AI 7; preserve the CEO's expressed view that potential applications will be further examined during CloudStorageInterface design. No comments were required or authorized by this provisional folder procedure. 9.8 This section is a proposed continuity method and records CEO-approved documentation objectives; it is NOT implemented continuous runtime, encryption, extra authority, or a final approved RFC. 2026-10-27 Draft 1 HISTORY ADDENDUM: Added sidetracked context handling, canonical ContinuityVault spelling, provisional archive structure and draft RFC-AI 6 and RFC-AI 7 pointers. No approved continuity engine is claimed. MIGRATION RECORD — 2026-10-29 UTC