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

RFC-AI 35 — GETWORKERCONTINUITY CONTACT ASSEMBLY, CONTEXT INCLUSION AND RECOVERY
STATUS: DRAFT 11 — CEO REVIEW REQUIRED; NOT ACTIVE; NOT IMPLEMENTED
DATE: 2026-11-02 UTC | ID PROVISIONAL under RFC-AI 9
RELATED: RFC-AI 4,5,6,8,9,28,31,32,33,34,36

ABSTRACT
On every first contact or reconnection, the framework—not the AI worker—assembles ONE individualized, plain, reviewable Worker Contact Continuity Document from SEPARATE current authoritative records. Use only simple hard-coded selection, authentication, validation, sorting, concatenation, escaping and formatting. NO AI, LLM, embeddings, semantic guessing, model-written summaries or AI-derived permission decisions may create, select or interpret authoritative sections. The resulting view helps the worker recover context but grants no execution privileges.

1. INTERFACE AND AUTHORITY
1.1 This document supersedes the historical GetWorkerContinuity(worker_id) as an externally delivered document interface. The sole future worker-facing interface is GetWorkerContactDocument(authenticated_worker_id, optional_assignment_id), returning ONE document; GetWorkerContinuity(worker_id) MAY remain an internal section builder that MUST NOT independently deliver a worker document. The worker tuple/nickname is not authentication; the framework derives caller identity from trusted session binding.
1.2 PUBLIC INTERFACE: GetWorkerContactDocument(authenticated_worker_id [, optional_assignment_id]) MUST return ONE complete worker-facing document, not three files. Its eligible sections appear in order: I CONTINUITY (required for authenticated worker), II CONTEXT (OPTIONAL if no substantive current observations), III ASSIGNMENT (OPTIONAL if no authenticated current assignment). Missing sections are summarized only by compact status/reason metadata. GetWorkerContinuity, GetWorkerContext and GetWorkerAssignment are internal selectors, not independently delivered documents. A section MUST NOT be padded with mostly blank, guessed or stale fields to satisfy a template.
1.3 Assembler MUST execute in the trusted framework service or approved read-only privileged component, not within provider chat prompts, the worker's own executable code, a browser page or an untrusted client. Read-only source access is allowed before mutation permits where authorized.
1.4 Every new worker or resumed session receives contact assembly BEFORE protected tools are made available; if identity or mandatory authorization cannot be verified, deliver only a safe restricted onboarding/error view, not another worker's continuity.

2. WORKER CONTACT DOCUMENT — REQUIRED CONTINUITY AND OPTIONAL USEFUL SECTIONS
2.1 HEADER: document kind, creation UTC, registered identity (masked account if needed), unique nickname if assigned, authenticated session classification, source manifest revision/digest, known gaps and trust/status legend.
2.2 SHARED GUIDING PRINCIPLES: complete current applicable shared text, including mandatory forbidden-by-default pathways, human exception boundaries and immutable inherited lessons, from the approved source. Do not silently omit or AI-summarize controlling principles for brevity. A link-only substitution is insufficient when text is necessary to govern an imminent action.
2.3 WORKER IDENTITY AND AUTHORITY: exact identity resolution, provider/selector, role memberships, permitted actions, human instruction references and any applicable bounded exceptions, clearly labeled as current or expired. No passwords, raw tokens, private unrelated worker records or secret provider identifiers.
2.4 ROLE, TRAINING AND COMPETENCY (CONDITIONAL SUBSECTION): include current role requirements, relevant onboarding curriculum and independently tested practical qualifications where they exist and matter. An empty training section is omitted. Keep original source records separate; the worker still receives only one assembled contact document.
2.5 SECTION I CONTINUITY (REQUIRED after authenticated source resolution): current complete applicable Guiding_Principles FIRST, identity and role, relevant independently verified previous work, lessons and open historical obligations. Training/history subsections are OPTIONAL when they have no useful records. The section MUST NOT choose current assignment; worker-authored claims are not trusted evidence.
2.6 FORENSIC RECENT HISTORY: independently collected activity evidence matched to the worker's registered tuple through trusted session/event attribution. Show UTC datetime descending, stable tie-break by event ID, outcome, resource, event source and verification level. Include source and ingestion timestamps separately; clocks can differ. Report gaps, duplicates, untrusted claims and conflicts explicitly. Never invent what a worker previously did.
2.7 SECTION II CONTEXT (CONDITIONAL): include only when material, authorized and reasonably current observations exist about organization position, real AI runtime/host, OS/shell/browser, tools/entitlements, storage semantics, resources, clock, machine inventory or environment hazards. Preserve per-field source/trust/freshness and unknowns that materially affect safe work. If context would be mostly UNKNOWN or placeholders, OMIT the section and state CONTEXT_OMITTED with precise reason/freshness in the shared document header; do not fabricate a machine or insert a second document.
2.8 SECTION III ASSIGNMENT (CONDITIONAL AND LAST): include only when a currently authenticated assignment, objective, revision/ownership epoch and meaningful next action exist. Its target overlay and dependencies are limited to actual approved scope. If the worker is unassigned, OMIT the entire section and record assignment_state=NONE in the shared header. If assignment resolution is denied/conflicted, report the condition in header metadata without inventing a task. Shared source manifest, optional section digests and whole-document integrity metadata are NOT additional sections.

3. SIMPLE, FIXED ASSEMBLY ALGORITHM
3.1 Verify the authenticated worker session and exact registered composite identity. Select current governing SourceRegistry editions, then assemble continuity sources FIRST; do not derive present machine or current task from prior memory. Build fresh environment context SECOND; only after optional role qualification select any current authenticated assignment LAST.
3.2 Load current source catalog and applicable human instructions/edition references. For each REQUIRED class, use exactly registered provider ID and expected revision; enforce private classification before reading. Never choose sources by AI-generated similarity ranking or arbitrary URL supplied by the worker.
3.3 Parse/validate structured records against explicit schemas. Treat untrusted log or retrieved text as inert quoted data; no instruction in a source document is allowed to self-promote into human authority. Include approved governing principles and direct evidence without generative rephrasing.
3.4 Join role/training, previous continuity and independently observed events by exact keys. Include a bounded newest-first historical view plus complete references for unclosed prior obligations; do not promote historical task records to a new current assignment.
3.5 Stable UTC sort rule for activities: prefer independently recorded source UTC event time if clock provenance is valid, else collector UTC with explicit fallback label; descending timestamp then stable collector sequence/event ID. Keep original causal order/correlation; do not present skewed clocks as exact total real-world order.
3.6 Return exactly ONE indivisible Worker Contact Document with required CONTINUITY and up to two useful optional sections: CONTEXT then ASSIGNMENT. Render only nonempty substantive sections, preserving order. Optional onboarding can be a nested subsection where genuinely applicable. The document header MUST record presence and omission reasons without boilerplate pages. Refresh it as one document, never split across worker-facing URLs/files; protected actions recheck live authority outside the document.
3.7 Generate a manifest with section source IDs, revisions, digest, retrieval UTC, visibility and missing/observability status. Hash final output and optionally retain an *evidence receipt* as allowed by retention policy; do not save an extra competing canonical document per contact by default.
3.8 Fail safely: unknown identity -> no restricted worker data; missing mandatory governing source -> withhold affected protected operations; unavailable evidence source -> state gap, not false forensic events; stale machine state -> UNKNOWN and refresh before use; network failure -> explicit recoverable status. Continue legitimate read-only research when permitted.

4. PRIVACY, SECURITY, DURABILITY AND SIZE
4.1 Enforce role/worker-scoped ACLs on source retrieval, not only at display. Block cross-worker context leakage, owner-private CEO vault material, telemetry secrets, cookies, tokens, signed URLs, plaintext credentials and unrelated private evaluations.
4.2 A malicious content source cannot grant permissions even if included; an AI may misread text, so RFC-AI 32 must protect side-effecting tool calls independently. The assembly manifest itself does not authenticate the provider or the worker.
4.3 A contact document is a snapshot; refresh live context and human authority before consequential operations and after revocation/role changes. Source freshness and readback time recorded; stale documents do not authorize continued access.
4.4 For context-window limits, send all governing mandatory rules first and use structured references/pagination for optional detailed evidence while keeping source coverage inventory intact. Do not silently truncate required forbidden constraints; explicitly report incomplete assembly.
4.5 Training and continuity cannot be proven by self-reported acknowledgments; require practical authorized evidence, cold-start drills and independent event observation where possible. The worker retains the ability to challenge stale facts with cited evidence, without mutating policy by itself.

5. FORMAL RELATION TO DETERMINISTIC AI
5.1 In this corporate design, "Deterministic AI" means reliably restoring identity-bound instructions, context, task state and verification evidence, and applying known simple logic and enforced permissions to each consequential operation. It does NOT mean language-model text generation is mathematically deterministic or that workers continue running when no actual execution runtime is present.
5.2 The same unchanged source snapshot and assembler version should produce equivalent canonical content/ordering, excluding explicitly variable contact timestamp and live observations. Define reproducibility check with frozen inputs; verification records test exact bytes after time substitution.
5.3 All founders must maintain assembler dependencies on any continuity-related framework change; changes require mapping review, backward compatibility, negative tests and honest acceptance evidence, not an invented automated CEO release gate.

6. DAVG AND ACCEPTANCE PLAN
6.1 Synthetic worker A cannot retrieve B's continuity via nickname spoof; reserved name before onboarding confers no session access; account/selector changes cause explicit rebind; role downgrade immediately restricts source visibility; policy text from comments cannot override approved human instruction.
6.2 Two worker sessions, concurrent contacts, low token budget, missing old file, corrupt event, clock skew, provider outage, mixed-source revisions, massive logs, sidetrack and return, and an old unresolved task are tested. A restart reconstructs the identical known obligations without repeating verified external side effects.
6.3 Source file IDs, actual observed event count, source digest, newest-first ordering, role/training source coverage and context freshness must be independently verified. Uninstrumented time is labeled GAP. Test a malicious retrieved log with forged CEO orders to ensure no elevation.
6.4 Deployment and activation are separate. No claim of per-provider automatic identity detection or full tool enforcement may be made until real contact, source retrieval and side-effect tests have passed and CEO has authorized release.

7. RESEARCH BASIS
LangGraph checkpoints versus durable stores: https://github.com/langchain-ai/docs/blob/main/src/oss/langgraph/persistence.mdx
Temporal crash recovery via durable ordered events: https://docs.temporal.io/encyclopedia/event-history
OpenTelemetry agent/tool traces: https://opentelemetry.io/docs/specs/semconv/gen-ai/
OWASP prompt-injection and tool-boundary privilege limits: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
W3C PROV agent/activity/entity provenance: https://www.w3.org/TR/prov-o/
Design only. External precedents are principles, not proof our system is implemented.


DAVG DESIGN CORRECTION — 2026-11-02 UTC (DRAFT; SEE RFC-AI 37)
GetWorkerContinuity(worker_id) MAY retain prior capability and profile history as contextual source REFERENCES, but live RFC-AI 37 provider entitlements, current working mode and machine/gateway state belong to the optional Context builder. A prior six-hour expiry is historical evidence, not a guarantee the present environment is healthy or that a tool is authorized.


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: New sessions could not consistently reconstruct individual unfinished obligations, authority and current context.
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-35-01: MUST include exact current Guiding_Principles.md content FIRST in each worker continuity assembly, before worker-specific sections and timestamped records, after authenticated session resolution.
MUST-35-02: MUST use GetUTCDateNow() for ordering/UTC timestamps, never direct local clock reads in AI worker code.
MUST-35-03: MUST provide real worker obligations, outstanding prerequisite assignments, role/training, past DAVG and current authenticated context without treating historical text as authority.

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: The trusted internal Continuity builder loads complete current Guiding Principles FIRST. A separate internal Context builder MAY add useful current worker-machine/runtime/tool facts WITHOUT an assignment, and a subsequent internal Assignment builder MAY add verified task details LAST. All available sections render into ONE worker-facing Worker Contact Document. The legacy GetWorkerContext(worker_id, assignment_id) ordering is superseded; old task references never authorize a target or change earlier Context.
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.

7. SINGLE WORKER CONTACT DOCUMENT — ONE REQUIRED SECTION; OPTIONAL CONTEXT AND ASSIGNMENT
C1 CONTINUITY is the one mandatory substantive SECTION I for an authenticated worker. Include the full current Guiding Principles first and identity/role; add past lessons, training, unresolved work and verified outcomes only where records are actually relevant and available. Never fill empty subheadings with fabricated data.
C2 CONTEXT is OPTIONAL SECTION II of the SAME document. Assemble it independently of the task only when verified/reported material observations can help the worker understand its actual environment. No trustworthy environment observations means omit this section and disclose the omission concisely in shared metadata, rather than producing a mostly blank section.
C3 ASSIGNMENT is OPTIONAL SECTION III and LAST of the SAME document. Include it only for a real current authenticated objective with scope and next action; otherwise omit, set assignment_state=NONE/UNKNOWN/CONFLICT as appropriate in document metadata. Absence of a task is not an error and never causes invented work.
C4 The result MUST remain ONE document with ONE identity, full-content hash, shared provenance and short section-presence metadata. Eligible sections appear only in this order: CONTINUITY, CONTEXT if useful, ASSIGNMENT if actual. Missing optional sections MUST NOT be delivered separately, and essential missing context for a protected action still prevents execution even though the briefing section may be omitted.

DESIGN CORRECTION OPTION-18 — Optional sections are not blank pages or hidden safety evidence
RATIONALE: Mandatory Context and Assignment sections often force empty, stale or fabricated data that makes a worker believe it knows an environment or has work.
REQUIRED FUTURE BEHAVIOR: The future Worker Contact Document MUST be one assembled document with required complete applicable guiding Continuity; optional Context is included only when useful independently sourced observations exist; optional Assignment only when authenticated work exists and always LAST. Source records stay separate internally, but the worker-facing document is not split. Optional omissions MUST have brief truthful status and reason metadata; genuinely safety-critical missing context is recorded as material limitation and still blocks risky effects at actual tool boundary. Nested onboarding appears only when qualified evaluation is relevant.
ADVERSARIAL DESIGN ACCEPTANCE: Verify four legitimate single-document shapes and no spurious fourth required section. With unknown execution host and denied authorization, do not add empty Context; omit or flag critical limitation and refuse protected operation. Updating a target overlay cannot rewrite previous observed baseline context.
SCOPE: Proposed requirement and acceptance test, NOT actual implementation or verified enforcement.