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

RFC-AI 44 — ASSIGNMENT-BOUND WORKER CONTEXT AND ARCHITECTURAL WORKFLOW ASSEMBLY
DOCUMENT CLASS: STANDARD — FUTURE DESIGN
STATUS: DRAFT FOR CEO REVIEW; ENTIRE RFC-AI SYSTEM UNIMPLEMENTED
DATE: 2026-11-02 UTC
RELATED: RFC-AI 3, 8, 11, 12, 17, 20, 21, 22, 23, 24, 27, 31–43, 45

1. PURPOSE / COMPETENCE
Every worker MUST know where in the corporate objective workflow it is working, why that piece matters, which prerequisites and authorized approvals apply, what progress is actually independently observed, and its available real machine/tool environment. The context is assembled by simple independently running logic; the worker cannot forge context authority by editing files. GetWorkerContinuity(worker_id) MUST place current shared Guiding_Principles.md FIRST, while GetWorkerContext(worker_id, assignment_id) provides an assignment-specific snapshot afterward. Worker_id is the RFC-AI 33 type+provider+selector+account identity, verified against an authenticated live session; nickname alone is not authority.

2. DEFINITIVE WORKFLOW
W0 AUTHENTICATED WORKER IDENTITY/SOURCE EDITION -> W1 IDENTITY-BOUND CONTINUITY ASSEMBLY (complete Guiding Principles FIRST) -> W2 INDEPENDENT OPERATING CONTEXT ASSEMBLY (actual worker runtime, machine, tools, storage, clock and UNKNOWN; NO assignment required) -> W3 ONBOARDING/QUALIFICATION IF REQUIRED -> W4 AUTHENTICATED CURRENT ASSIGNMENT LAST (objective, epoch, pieces, target overlay) -> W5 DEEP RESEARCH -> W6 DEPENDENCIES/RFC/INTERFACE APPLICABILITY -> W7 AUTHORIZED EXECUTION -> W8 INDEPENDENT EFFECT VERIFICATION -> W9 CROSS-INTERFACE RECONCILIATION -> W10 DAVG/DOMAIN REVIEW -> W11 HUMAN PIECE APPROVAL WHERE REQUIRED -> W12 VERIFIED DELIVERY AND CONTINUITY LEARNING. W4 is LAST among the three worker documents, NOT the end of execution. Transitions carry independent evidence and invalidation, not just a status flag.

3. INPUT AND AUTHORITY
The bootstrap MUST return ONE Worker Contact Document. It contains the required substantive CONTINUITY section, followed only when useful by optional CONTEXT and only when currently assigned by optional ASSIGNMENT, always LAST. Section order is fixed; section presence is conditional. NEVER manufacture empty headings, duplicate files or placeholder-filled sections. GetWorkerContinuity, GetWorkerContext and GetWorkerAssignment are internal source/section builders, not three worker-facing documents. The common header includes exact section presence, omission reason, trusted source manifest, document revision and full-document SHA-256. Missing security-critical facts still block consequential operations, irrespective of whether their display section is omitted.

4. AUTHORITATIVE SOURCE BOUNDARIES
Inputs: SourceRegistry(edition/ID/revision), Guiding_Principles.md, worker identity and verified session binding, assigned role/role expertise certificate, current authenticated human objectives and piece plan, RFC-AI/Standard applicability, approved tool catalog, current machine inventory/attestations, worker task and prerequisite dependency graph, research-source receipts from independently observed source-read operations, actual provider/storage event receipts, user-delivered assets and approved projects. Distinguish each input as TRUSTED_BOUNDARY_EVENT, INDEPENDENT_PROVIDER_OBSERVATION, HUMAN_AUTHENTICATED_APPROVAL, CURRENT_AUTHORITATIVE_RECORD, NON_FORENSIC_WORKER_CLAIM, EXTERNAL_UNTRUSTED_REFERENCE or UNKNOWN. Worker-authored content must never be upgraded into proof of execution. See RFC-AI 45.

5. CANONICAL SNAPSHOT CONTRACT (VERSION 1)
Return ONE contact document with shared identity/source/edition/whole-content integrity and optional nested subsections. CONTINUITY is required after worker authentication: complete applicable Guiding Principles FIRST, identity/role, useful verified lessons, training history and prior obligations. CONTEXT is conditional: actual current runtime/OS/host, organization, tools/entitlement, storage and resource signals with per-field provenance; omit if almost entirely unavailable and state omission reason in shared metadata. ASSIGNMENT is conditional: include only current authenticated task/revision/epoch, project pieces, target overlay, approvals and next action, otherwise omit and record assignment_state=NONE/UNKNOWN/CONFLICT in header. There are never three separate worker documents.

6. DETERMINISTIC ASSEMBLY ALGORITHM
A. Authenticate current worker and source registry; capture worker identity/session without retrieving or selecting a current assignment.
B. Populate SECTION I CONTINUITY of the one in-progress worker document. Include complete Guiding Principles first, worker identity, verified role/history, lessons and prior obligations. Do not emit a separate document.
C. Gather independent current operating context without an assignment. Include optional SECTION II only when its observed/reported facts materially help orient the worker. Omit boilerplate and empty observations; record relevant critical omissions in shared metadata. No standalone Context document.
D. Add optional onboarding/training or qualification information only where applicable and useful; nest it within Continuity/Context as appropriate, not as a required fourth section.
E. Resolve authenticated current human work LAST. Include optional SECTION III ASSIGNMENT only for an actual relevant task. If none, omit the section and put assignment_state=NONE in the single document header. Never introduce work or a fictitious target merely to populate a required heading.
F. Continue actual work W5-W12: research, applicable contracts/dependency design, bounded authorized execution, independent provider/physical verification, cross-service reconciliation, DAVG, authenticated per-piece human approvals and delivery with learning. Invalidated stages and unaffected accepted pieces MUST be distinguished.
G. Missing or stale facts MUST be communicated concisely in document-level status/omission metadata when their section is absent, or within relevant present sections when material. Reassemble the WHOLE single document on relevant changes; authorization remains independently enforced by the actual tool boundary.
H. Hash and version the entire unified worker contact document. Optional section digests support integrity inspection but MUST NOT create independent source authorities or separate worker files. A hash is not approval or authentication.

7. HUMAN-APPROVED PROJECT PIECES
Project objectives are partitioned into typed pieces from full project creation (piece_id, human-understandable objective, upstream dependencies, artifacts, independent acceptance/evidence, specialized worker roles, model/OS/Interface constraints, human approval requirement, revision, authority). Human approval/rejection occurs per piece and per revision. An authenticated human may reject one piece with exact correction notes, while accepted others remain accepted unless a version/dependency invalidates them. A worker-generated status string NEVER constitutes human approval. Store planned and actual states separately. Piece assembly, final project completion and related-effect consistency are independently evaluated. An approval event cannot be reused for a different piece/revision. Human involvement remains limited to actual designated gates, e.g. favicon swatch/art selection, not routine engineering.

8. EXPERTISE / ROLE QUALIFICATION
Before independent expert work, obtain actual role+curriculum, administer role-appropriate objective questions and practical task scenarios with fixed/simple-logic scoring and independently verifiable evidence; failures trigger immediate correction, retraining and distinct retest. A role identity or AI-written training file does not qualify a worker; no unsupervised expert assignment until minimum competence actually proven. Role examiner/test engine owns technical scoring. Renew evaluation on material role changes.

9. SECURITY, FORENSIC, PRIVACY AND FRESHNESS
GetUTCDatetimeNow() is the proposed canonical UTC-instant Interface under RFC-AI 8. Historic GetUTCDateNow() callers require a versioned compatible adapter; it MUST NOT be confused with a date-only value. Observe clock health and causal ordering independently; timestamps never authenticate.

10. PROPOSED VERIFICATION CASES (BEFORE IMPLEMENTATION)
Synthetic identity A cannot access B; wrong assignment machine stays rejected; moved assignment invalidates previous snapshot; old worker cannot commit after reassignment; approved piece survives rejected sibling; spoofed human APPROVED is ignored; invalid role qualification cannot claim expertise; no forensic collector produces UNKNOWN not fabricated PASS; old source receipt cannot justify later changed source; advertised entitlement not accepted; missing collector/clock records show uncertainty; merged `GetWorkerContinuity` always starts with exact Guiding Principles; cold start reconstructs current workflow stage and open subtask from independent sources; multi-service partial operations stay incomplete; no unauthorized privileged tool permission. A synthetic reference assembler may validate document formatting only, NOT deployment.

11. OWNERSHIP / DESIGN STATUS
This is a precise candidate Standard, not active corporate policy. GetWorkerContext runtime, event collector, machine agents, authenticated worker registry, authoritative source catalog, competent role examiner and provider adapters DO NOT yet exist as verified RFC-AI deployments. Their actual interfaces own implementation and tests. Stage/schema/exception choices remain proposed until CEO adoption. All project objectives and approved work pieces must preserve these requirements.

12. EXTERNAL RESEARCH BASIS
OpenTelemetry Context Propagation (trace correlation not authority): https://opentelemetry.io/docs/concepts/context-propagation/
W3C Trace Context and trust/metadata leakage: https://www.w3.org/TR/trace-context/
OWASP Logging event vs recording time, interaction IDs, tamper/security limits: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet
Azure Durable Functions human approval events/deduplication: https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-external-events
SLSA provenance/independent producer: https://slsa.dev/spec/v1.0/provenance

13. ONE CONTACT DOCUMENT — OPTIONAL SUBSTANTIVE SECTIONS
T1 The worker receives exactly ONE contact document containing required Continuity, optional substantive Context and optional authenticated Assignment in order, rather than three files or three mandatory blank panels.
T2 An unassigned worker receives the same single document WITHOUT an Assignment section and with assignment_state=NONE in compact header metadata. A worker without meaningful context observations receives no Context section and an accurate context omission reason. Continuity and applicable Guiding Principles remain intact.
T3 Context within SECTION II has per-field source, observed UTC, TTL, trust class and UNKNOWN/CONFLICT. Worker inference runtime, actual host, human workstation and future task target are distinct identities.
T4 Assignment inside SECTION III binds current human objective, epoch, target and per-piece approvals without rewriting SECTION II. The overall document integrity covers all three sections.
T5 Negative test: reject separate worker files, empty placeholder-heavy optional sections, fabricated tasks or made-up current machine data. Confirm conditional presence, fixed ordering, full-document integrity and protected-boundary authorization.
T6 The worker's 'where am I' claim means a current evidence-graded snapshot refreshed by actual runtime on startup, material change, TTL expiry and protected operation—not continuous omniscience.

DESIGN CORRECTION CONTACT-07 — One useful Worker Contact Document and honest environment context
RATIONALE: Three separate documents and mandatory blank sections violated the existing source model and created false context obligations.
REQUIRED FUTURE BEHAVIOR: The assembler MUST emit ONE worker-facing document, never three independent documents. Section I CONTINUITY is required, includes the complete current governing Guiding Principles FIRST and identity-bound lessons/history where relevant. Section II CONTEXT is optional when substantive fresh observations exist about organization position, actual AI provider/runtime, execution host, OS, tools, credentials/entitlements (never secret values), mounts, clock, resource constraints and source trust. Section III ASSIGNMENT is optional and LAST, included only for authenticated work with ownership epoch, objective, target overlay and approvals. Absent sections MUST be represented by concise reason/status metadata, not blank pages; critical unknowns still block unsafe effects. Onboarding is nested where relevant.
ADVERSARIAL DESIGN ACCEPTANCE: Test single document in all four valid shapes: Continuity; Continuity+Context; Continuity+Assignment; Continuity+Context+Assignment. Reject split files, fabricated assignments, inferred human workstation, context-dependent target selection and untruthful omission of critical risk.
SCOPE: Proposed future contract, NOT running RFC-AI functionality; implementation HOW remains assigned to relevant Standard/Interface.