#!RFC-AI/2;id=20;draft=4;v=0.4.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=95be2f5ad4ee93e27061dc542295a27e04233450d73a2c2bb3fcd5cdbb30363c
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 20 — WORKER COLLABORATION AND SHARED CONFERENCE
DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE
STATUS: DRAFT FOR CEO REVIEW — ENTIRE RFC-AI SYSTEM UNIMPLEMENTED

1. PURPOSE — WHAT AND WHY
Coordinate workers to complete genuine shared objectives. Collaboration is meaningful only when a qualified worker accepts responsibility and returns independently acceptable work; sending a message is not delivery.

2. INTELLIGENT-WORK DIRECTION
Use the worker coordination Interface to contact the responsible role, maintain durable prerequisite assignments and real follow-up through an executing runtime, review the returned work and resume original obligations.

3. PROPOSED IMPLEMENTATION APPROACH
Use the relevant authorized Interface, component and expressly designated Standard: worker-coordination Interface, RFC-AI 31 and 35. Investigate the complete relevant context before deciding what the assignment means (see RFC-AI 11). A competent worker may discover, invent and improve the necessary methods during implementation; this guiding AI RFC is not required to repeat low-level APIs, algorithms or technology choices. Previous and legacy systems are research evidence only, never an implementation of this draft.

4. EVALUATION AND ACCOUNTABILITY
Use independent DAVG as described in RFC-AI 22 to challenge whether the eventual real-world result meets the objective, not whether the AI RFC looks like a traditional API specification. A missing prerequisite creates an active cross-worker recovery obligation through the worker coordination Interface, not a reason to abandon the task (RFC-AI 20 and 31). Report only verified effects and preserve lessons without reintroducing old operational mistakes.

5. DESIGN CUSTODY
Original subject-specific intended contract: Human availability separate from AI worker participation, conferences by identified session, queued approvals, structured handoffs, provenance, deconfliction and no secret propagation.
Implementation tasks, legacy-derived candidate methods, proposed data schemas, tests and open engineering questions are kept with this draft's append-only objectives.txt or the responsible Interface/Standard. This RFC has NOT been implemented; it does not approve a deployment or create a new CEO release gate. Rewritten 2026-11-02T20:28:09.285Z.


## HISTORICAL FAILURE EVIDENCE — RESEARCH ONLY; NOT AN RFC-AI IMPLEMENTATION
Historical context: Extension/broker receipt was confused with actual AI-model receipt and accepted work; disconnected sessions appeared as workers.
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-20-01: MUST continue seeking qualified collaborators after failed contact, unsuitable results or absent replies; vary the role, contact channel, research approach or request based on evidence instead of repeating blindly.
MUST-20-02: MUST distinguish sent, transport-accepted, actual worker-acknowledged, task-accepted, delivered and independently-verified results.
MUST-20-03: MUST assign unanswered, failed or unfulfilled work to other eligible workers while keeping durable dependency links and not losing original ownership.

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: Coordinate assigned pieces, actual qualified-worker receipt, alternate workers and resource fairness. Reject stale worker ownership, circular prerequisites and unverified message-based completion.
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 REVIEW ADDENDUM 2026-11-03 — COLLABORATION RECEIPTS
REQ-AI-20-COLLAB-001: A conference message sent, broker ACK, AI-tab receipt, actual worker acceptance, task execution, provider commit and verified result MUST be separate states with evidence. Shared human presence and independently enabled AI worker presence are separate; an unavailable human does not imply worker absence.
REQ-AI-20-COLLAB-002: Assignment ownership is durable across message retries, with stable IDs, dedup and bounded lease recovery; worker Continuity and Context MUST not be overwritten by collaboration chat text.