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

RFC-AI 36 — WORKER OPERATING CONTEXT, MACHINE DISCOVERY AND EVIDENCE FRESHNESS
STATUS: DRAFT 8 — CEO REVIEW REQUIRED; NOT APPROVED/IMPLEMENTED
DATE: 2026-11-02 UTC | ID PROVISIONAL under RFC-AI 9
RELATED: RFC-AI 4,5,8,9,28,31,32,33,34,35

ABSTRACT
Durable continuity describes retained instructions and unfinished historical work. Context is an independently assembled CURRENT environment view when meaningful observations exist. It MAY contain verified present execution host, AI runtime, machines, gateways, permissions, storage, resource pressure and clock. Human workstation and task target are separate unknowns unless independently verified, and task target is assigned only in the later optional Assignment section of the SAME Worker Contact Document. Do not promote remembered machines into present facts.

1. DISTINCT IDENTITIES AND SOURCES
1.1 HUMAN_SESSION_MACHINE: current machine associated with an authenticated human client session, only if verified/available. WORKER_EXECUTION_ENVIRONMENT: actual browser/API/runtime service hosting the worker instance. TASK_TARGET_MACHINE: machine(s) explicitly named/authorized for a current task. ADMINISTRATION_GATEWAY: current tool/service used to reach each target. These four items MUST NOT be assumed identical.
1.2 Machine inventory comprises stable machine name, canonical provider or registered machine resource ID, operating-system family/architecture, configured host endpoints, service roles, available capabilities, accepted managed methods, source revision and ownership classification. Reachability/online/offline status is NOT stored as a permanent machine trait.
1.3 Task requirements specify exact target identity or allowed selection constraints; machine selection is matched by simple typed rules, never guessed from nickname, IP address proximity, a worker's memory or a most-recently-used hostname. User-selected machine may be UNKNOWN until observed; the framework must not claim to detect a current human computer from an unrelated past session.
1.4 Example only: a human on workstation "sol", worker executing via a hosted Chat provider session, and a task targeting "peostectica-alpine-01" are three different identities. This example is not proof of an actual current user device or live worker connection.

2. CONTEXT SECTION BUILDER — PART OF THE ONE WORKER CONTACT DOCUMENT
2.1 GetWorkerContext is an INTERNAL stage of assembling one Worker Contact Document. Observe relevant current organizational position and actual worker environment without requiring a task. Return contextual facts to the trusted assembler; NEVER a separate worker-facing file. Emit optional CONTEXT SECTION II only when material authenticated or transparently classified reported observations exist.
2.2 Context fields are CONDITIONAL, not a mandatory empty matrix. Include useful known actual provider/runtime/host, OS/arch/shell/browser, authenticated gateways and entitlements, network/storage/mount caveats, machine inventory, clock and resource signals, source/revision/trust/freshness and meaningful uncertainties. Do not fill blank fields with guessed identities or huge UNKNOWN tables. If too little substantive evidence exists, OMIT the worker-facing CONTEXT section and record short context_status/reason in document metadata.
2.3 Machine health observations must be actual responses from authenticated endpoints (e.g., service health, TLS, approved inventory agent) or explicitly labeled self-report. A successful ping does not prove application availability, root access, provider identity or task authorization. No generic IP-only location proof.
2.4 Enforce a documented per-signal freshness policy (not an invented universal six-hour period). Example: endpoint health may need seconds/minutes, managed inventory may remain valid longer, human's current device may be unknown after session change. Clock synchronization/UTC health is covered by RFC-AI 8; record skew or ambiguity and prefer collector sequence for causality when event clocks are unreliable.
2.5 When context becomes material or stale, rebuild the SAME SINGLE Worker Contact Document with required continuity and whichever optional sections have substance. Do not persist a standalone context document. The context builder remains independent of the assignment; an assignment-specific target overlay belongs only in the final optional Assignment section. Boundary authorization never relies on a document snapshot alone.
2.6 On unavailable collector, missing authenticated device binding, conflicting inventory or incomplete network visibility, return UNKNOWN/CONFLICT/UNAVAILABLE with evidence; do not substitute the last seen machine as CURRENT. Safe read-only research may continue where authorized. Do not broaden target scope to a different machine to bypass a restriction.

3. MACHINE INVENTORY AND GOVERNANCE
3.1 Human-facing machine names should be stable, obvious and unique within the registered machine inventory: Machines/<MachineName>/inventory.json and readme.txt after canonical-path reconciliation under RFC-AI 34. Existing machines and live config must be inspected before writing or inventing a new folder. Machine addresses may change while stable identity remains.
3.2 Inventory edits require authorized administration with revision matching, audit readback and reference to the affected deployment. Machines may hold necessary runtime state; authoritative configuration/source documents remain private corporate Drive unless an approved policy says otherwise.
3.3 Access grants and machine capabilities are separate from the name: a worker may be permitted to read inventory but not run admin commands; human instructions may allow temporary development, testing or troubleshooting exceptions only within authenticated approved scope and expiry.
3.4 Normal privileged operations require complete RFC-AI 32 mediation across every actual entry route; an optional prior human exception must still be explicit, scoped and attributable. A context record MUST NOT authorize root operations or provide bypass access. A machine or gateway listed as present is not proof of a worker grant.

4. FORENSIC EVIDENCE VERSUS LIVE STATE
4.1 Old session facts and past machine connections belong to forensic events and continuity history with original UTC, actor, source, outcome and revision. They are NOT automatically promoted to live context. A machine status event can be included as historical evidence; new context must requery a trusted live source.
4.2 Collect evidence from allowed gateway receipts, provider audit metadata, machine agents, task events, source/revision readbacks and other supported instrumented tools. Correlate worker identity and task with exact authenticated session binding; expose coverage/observability gaps for uninstrumented browser or provider activity. AI-authored summaries are SELF_REPORTED, not independent forensic proof.
4.3 Sort forensic events in worker contact newest observed UTC first with stable tie-breaking; preserve original ingestion time and causal order, mark clock skew. Task OPEN status must be derived independently from authoritative task records, not guessed from absence of logs.
4.4 Protect logs from forgery and disclosure, sanitize secret-bearing arguments/URLs, limit retention per policy and avoid distributing unrelated worker or CEO private device information.

5. CHANGE IMPACT AND TEST PLAN
5.1 Every founder or designated framework maintainer must assess continuity/context effects of machine inventory changes, service migrations, new gateway tools, providers/selectors, role permissions, task routing, time source and evidence collector changes. Update mappings and tests when relevant, with NO_IMPACT justified by recorded checks; do not create a new CEO release gate.
5.2 Test distinct human/worker/target machines, current machine unknown, task target changing, offline gateway, stale health, conflicting IP/hostname, revoked privilege, machine rename, multi-target task, offline clock, user switching computers, browser profile spoof, hosted API worker with no machine telemetry, and historical events contradicting current observation.
5.3 Test that a worker's tool action against the wrong machine or with expired exception is refused even if its contact document says it was previously permitted. Test no uninstrumented path can be claimed covered. Verify state by independent live status; do not claim any setup has been implemented solely because an RFC was saved.

6. RESEARCH BASIS AND LIMITS
Kubernetes separates node inventory and capabilities from dynamic scheduling/condition observations: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
Consul maintains service discovery separately from health data: https://developer.hashicorp.com/consul/docs/discover
Temporal durable event history supports continuity without duplicating side effects: https://docs.temporal.io/encyclopedia/event-history
OpenTelemetry standardizes agent/tool spans and resource attribution: https://opentelemetry.io/docs/specs/semconv/gen-ai/
OWASP recommends least privilege and tool-call validation outside LLMs: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
Examples are design precedents, not proof those tools are installed or applicable on Peostectica machines.

7. STATUS AND DEPENDENCIES
DESIGN ONLY. Before implementing, reconcile actual machine directories and existing runtime (e.g., historical Alpine and Windows tools), registered resource identities and authentication evidence, then adopt editorial RFC-AI 9 governance and secure policy integration RFC-AI 32. Source history preserved; CEO alone controls release approval.


DAVG DESIGN CORRECTION — 2026-11-02 UTC (DRAFT; SEE RFC-AI 37)
Live operating context includes optional "working-mode" and its verified/observed/unknown availability independently of task target and worker execution host. RFC-AI 37 owns provider refresh and mode choice; RFC-AI 36 records effective mode, provider snapshot revision, authentication session binding, machine/tool availability and observed UTC. Work/Chat are two modes of one identity, not separate selectors or employees. On switch, fresh GetWorkerContext and RFC-AI 32 action authorization are mandatory. Do not infer Work quotas, current machine, or mode-switch support from a past contact or a provider model catalog; return UNKNOWN/MANUAL_SWITCH_REQUIRED where appropriate.


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: Windows, Alpine, VM, hostname and current operator machine were confused; static machine metadata became stale.
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-36-01: MUST use GetUTCDateNow() to timestamp context and establish freshness, not direct clock readings; when clock trust is unknown, do not invent freshness.
MUST-36-02: MUST separate authenticated human machine, worker execution host and intended target OS/shell/privilege details, validating real capability before operations.

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: GetWorkerContext(worker_id, assignment_id) is defined by RFC-AI 44. The assignment, not assumed chat location, identifies target machine(s); execution host and user device are distinct. Feed tools, environment, current workflow stage and independent recent actions as classified context, not authority.
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. PREASSIGNMENT CONTEXT AND AWARENESS
CTX1 A worker MUST know where it exists in the organizational source tree and current governance edition, and distinguish AI inference runtime, local shell/gateway executor, human workstation and any future target. A target is UNKNOWN until assignment and authorization verify one.
CTX2 Context includes actual environmental affordances: host and operating system, shell/browser, service interfaces, storage mounts and cloud persistence semantics, authentication/entitlements, resource headroom, network and clock health, environment-specific hazards, source provenance and accessible or inaccessible evidence.
CTX3 Every field MUST identify observed or reported source, collector timestamp, freshness deadline and trust class; absence is UNKNOWN, contradiction CONFLICT. No context assembled by the AI worker itself may self-certify execution or authorization.
CTX4 Optional CONTEXT section is between required CONTINUITY and optional ASSIGNMENT in the ONE document. OMIT rather than pad when almost empty, but report context availability/omission in shared metadata. Optional onboarding belongs in an applicable subsection, not as a fourth top-level section. Re-observation requires a new revision of the unified document; no always-on monitoring is inferred.
CTX5 Cross-worker and private CEO environment information MUST be filtered at source ACLs. A worker MUST NOT infer the user's precise active machine from its own execution host.