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

RFC-AI 14 — CORPORATE GATEWAY AND EMPIRICAL EVIDENCE RECEIPTS
DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE
STATUS: DRAFT FOR CEO REVIEW — ENTIRE RFC-AI SYSTEM UNIMPLEMENTED

1. PURPOSE — WHAT AND WHY
Require trustworthy operational evidence. Worker narrative is not a substitute for observation of an action, its authorization and its outcome.

2. INTELLIGENT-WORK DIRECTION
Use the authorized CorporateGatewayAndAuthorization and relevant Interfaces to observe protected operations, obtain genuine receipts, distinguish independent measurements from inference and make claims only within verified scope.

3. PROPOSED IMPLEMENTATION APPROACH
Use the relevant authorized Interface, component and expressly designated Standard: CorporateGatewayAndAuthorization, RFC-AI 27, 32 and 39. 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: Authenticated typed gateway operations, exact preaction intent, provider response, revision/hash, independent readback, executed tests; self-report distinct from provider-confirmed facts; tamper evidence.
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 research: Pre-RFC legacy practices and incidents may be studied for negative examples, but no implementation of this RFC-AI yet exists.
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-14-01: MUST design its assigned function for actual authorized outcomes, independent evidence, context-first investigation, active recovery and no false implementation claims; refer to the relevant Interfaces and Standards.

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.

## DESIGN REVIEW ADDENDUM 2026-11-03 — INDEPENDENT GATEWAY RECEIPTS
REQ-AI-14-GW-001: Context MUST distinguish chat-provider runtime, tool host, authenticated gateway, target machine and human device. A connected or healthy tool MUST NOT be mistaken for authority to use it or for evidence that its effect committed.
REQ-AI-14-GW-002: Actual controlled effects require authenticated worker/human scope, target/epoch/revision checks at execution, and independent boundary/provider receipts. Discovery/read diagnostics remain available when a side-effecting request is denied; temporary root paths prevent a claim of universal enforcement.