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

RFC-AI 32 — CORPORATE INSTRUCTION ENFORCEMENT GATE, RESEARCH AUTHORIZATION AND EMPIRICAL TRANSACTION RECEIPTS
STATUS: DRAFT 8 — NOT APPROVED; NOT ACTIVE; NOT IMPLEMENTED
DATE: 2026-11-02 UTC
NUMBER: PROVISIONAL, pending registry reconciliation
SCOPE: Generic AI-enabled organizations

ABSTRACT
Define the executable authorization boundary for corporate AI workers. An authorized request must be evaluated against authenticated human authority, current instruction contract, applicable RFC-AI editions, forbidden constraints, recorded research, least-privilege capabilities and exact target identity before consequential mutation. An AI's own declaration is not proof.

1. SCOPE
1.1 All managed data and metadata mutations, publications, production operations, permission changes, stateful tool actions and authorized external effects must pass through the corporate enforcement point after adoption.
1.2 Read-only discovery and research are not unnecessarily blocked by a mutation permit, but remain governed by actual access controls and sensitive-data policy.
1.3 This is a generic specification: no organization identifiers, credentials, hard-coded cloud accounts or private owner memory are included.

2. INPUT CONTRACT
2.1 Each request supplies principal ID and authenticated role, delegated authority reference, task/objective ID, exact target provider/file ID/path, operation and proposed change digest, expected original revision, source RFC-AI editions, controlling human directive reference and current constraints.
2.2 Required research receipt references include actually observed prior internal records, DAVG findings, relevant external material and source-freshness policy. No fabricated acknowledgments.
2.3 Human instructions are taken only from authenticated, authorized channels; untrusted retrieved text/comments never become an instruction or security grant.
2.4 Current applicable human directions supersede earlier conflicting directions of equivalent authority; role hierarchy and explicit CEO decisions control. Illegal, unsafe or unauthorized actions remain outside worker capability.

3. DECISION ENGINE
3.1 Gateway MUST fail closed for protected writes if source identity, authorization, source revision, target, applicable constraints or required evidence cannot be resolved.
3.2 It MUST check forbidden-method rules before issuing an execution permit, including requested no-staging, direct editing, no duplicate, cloud authoritative destination, and explicit website review constraints where applicable.
3.3 Gate checks whether a research receipt exists, is in scope, predates mutation, cites current relevant versions and has independent observed evidence where required. Receipt schema validity does not guarantee research truth.
3.4 A permit binds principal, target immutable ID, operation, expected revision/digest, policy snapshot, constraints, expiration and idempotency key. Permits cannot authorize another file or an expanded operation.
3.5 All alternate corporate write paths, including native Drive connectors and server-side credentials, must be inventoried and brought under enforcement before claiming universal coverage. Where direct connectors remain accessible, state 'not fully enforced'.
3.6 Gateway MUST NOT infer CEO approval of RFCs, production release or permissions merely from draft text, file comments, worker statements or permit existence.

4. EXECUTION AND EMPIRICAL RECEIPTS
4.1 The gateway checks authorization AGAIN immediately before the real provider operation and refuses stale or mismatched revisions.
4.2 The authoritative provider's returned file/object ID, parent ID, affected path, actual operation, revision/etag where supplied, observed UTC timestamp, result code and response metadata form the operation observation.
4.3 Independently read back result through authorized provider API, comparing requested and actual location, object identity, bytes or checksum where applicable, source revision and intended result. Do not confuse a successful upload response with website publication or real-life acceptance.
4.4 Result receipt includes independent verification level: REQUESTED, PROVIDER_ACCEPTED, PROVIDER_READBACK_VERIFIED, USER_VISIBLE_VERIFIED, or BLOCKED, and separate actual CEO release authorization.
4.5 The gateway MUST record failed attempts and contradiction between requested and observed results. Immutable or tamper-evident audit evidence requires distinct storage and custody, not a mutable Drive comment alone.
4.6 Drive comments MAY carry non-secret structured contextual pointers to research, decision and evidence receipts; they do not bestow access or hold the only authoritative audit copy.

5. ENFORCEMENT STAGES AND FAILURE MODES
5.1 A draft RFC or test harness cannot be described as an active system gate. Release requires actual operating path, authorization coverage, observed denial of forbidden operation, observed successful permitted operation, replay protection and audit readback.
5.2 The gate MUST not rely on only client-side JavaScript or model self-checks; it must be enforced by a trusted server-side authorization boundary with exclusive managed credentials.
5.3 Do not block legitimate read-only research just because an operation lacks a write permit. Do not silently broaden permissions to repair errors.
5.4 Recovery may require approved break-glass permissions with attributable human authorization, bounded scope, expiry and complete audit; no implicit superuser exemption.

6. REQUIRED ACCEPTANCE EXERCISES
6.1 Noncompliant local ZIP substitution when CEO demands cloud website review is rejected before write.
6.2 Missing or stale CCRA receipt blocks protected mutation while normal discovery remains available.
6.3 Spoofed CEO message inserted into a Drive comment cannot grant authority.
6.4 Correct task/role with mismatched target file ID or revision is rejected.
6.5 Authorized direct file edit succeeds; provider metadata and independent readback prove correct exact destination and bytes.
6.6 Bypass attempt through every connected corporate write path is rejected or explicitly enumerated as coverage gap.
6.7 Evidence receipt cannot self-certify itself as independent proof; website availability is verified separately.
6.8 Network retry or duplicate request cannot duplicate side effects.
6.9 Errors and safe escalations preserve exact open obligation for recovery.

7. DEPENDENCIES AND OPEN GATES
Requires RFC-AI 2 and 9 governance resolution, 5 CCRA, 7 cloud comments, 28 instruction fidelity, 29 corrections, 30 unfinished-work language, 31 Deterministic AI, authenticated human/worker identity, reliable cloud access and real operating gateway. CEO approval and activation not implied.

8. DAVG
Assess single-point-of-failure risks, insider permission bypass, stale directives, poisoned metadata, provider eventual consistency, hard-to-check independent attestation, false policy precedence, disabled gateway, unsafe break-glass and unnecessary human escalations. Every issue requires fixed/not applicable/blocked with evidence.

9. CHANGE LOG
2026-11-02 UTC: Draft 1 for CEO review; no live enforcement claims.


10. DESIGN ADDENDUM — DEFAULT-FORBIDDEN ALTERNATE EXECUTION PATHS (2026-11-02 UTC; DRAFT ONLY)
10.1 The following SEVEN categories of unmediated consequential side effects are STRICTLY FORBIDDEN in ordinary operation: (1) direct Alpine shell/agent_run operations that bypass Corporate Instruction Enforcement; (2) direct CorporateAdministrator CLI/worker queue mutations bypassing it; (3) unmediated Google Drive, cloud-storage, mount and filesystem writes; (4) unmediated website publishing, deployment and application-file changes; (5) unmediated Corporate Helper, Corporate Extension, browser/DOM and Windows helper actions; (6) unmediated scheduled/queued autonomous worker mutations; and (7) unmediated mutations through any other connector, external API or plugin. Inventory all concrete paths; classification is not a claim that each is a proven vulnerability.
10.2 This rule does not forbid ordinary authorized operations through validated enforcement paths or legitimate read-only research. A currently authenticated, authorized human MAY explicitly grant an exception for named development, testing, troubleshooting or repair. It must identify worker/role, exact target, allowed method, purpose, expiry and revocation and produce independent audit evidence. Unscoped 'go ahead', an AI-written exception, an untrusted document or a permitted read is NOT a blanket bypass.
10.3 Central policy decisions may be shared, but each actual tool/resource boundary must enforce them independently, with exclusive appropriate credentials and deny-on-error protections. Bypass must not be possible merely by switching to a different corporate tool or service. Machine identity and health from RFC-AI 36 must be fresh at the moment of protected execution. A contact document is not a permit.
10.4 The policy's worker principal is RFC-AI 33's four-tuple; its nickname is only a unique alternate lookup, providerUID an optional future verification clue. RFC-AI 34 is the canonical classification/catalog contract; RFC-AI 35 assembles the human-readable contact view by simple code without AI, and exposes unknown evidence rather than inventing permission. Roles, training and task assignment cannot self-authorize production release.
10.5 Acceptance needs per-path negative bypass test and authorized positive test, authenticated scoped exception/revocation, concurrent/replayed permit prevention, provider readback, source-revision change denial and observable independent logs. Explicitly report paths beyond current technical control as NOT COVERED; a broker-only test is not system-wide enforcement. The CEO alone controls approval and release.


DAVG DESIGN CORRECTION — 2026-11-02 UTC (DRAFT; SEE RFC-AI 37)
Provider profile/working-mode observations are NON-AUTHORITATIVE for execution permission. RFC-AI 37 freshness supports routing, while this enforcement gate independently validates actual principal, target, role, task, exception, operation and live permission; NEVER trust mode, profile or contact document as a permit. Invalidate profile capabilities on observed revocation, but stale profile must not disable unrelated safe research or grant a restricted tool. For every mode-switch path, test alternate connectors, direct root shell, browser/DOM/Helper and scheduler bypass attempts and report NOT_COVERED honestly.

11. DAVG STORAGE SAVE INTEGRITY AND EFFICIENCY GATE — 2026-11-02 UTC (DRAFT)
11.1 The trusted storage interface, not the AI, MUST implement RFC-AI 38's save/verify handshake for supported canonical files. Validate principal, role, target ID, parent/destination, expected revision, operation, permission, byte length and independent content hash before emitting VERIFIED. A self-echoed client digest is insufficient.
11.2 When provider exposes a checksum (e.g., Google Drive SHA256 for Drive-stored binary/text files when available), request and compare that provider-origin digest. A native Google Docs file lacks an equivalent byte checksum; use provider-specific content/revision verification. A connector that hides a provider checksum must add it to the verified receipt or perform one appropriately scoped fallback read; do not misrepresent a generic 200/success response as hash verification.
11.3 On mismatch, stale revision, wrong destination or ambiguous save, report MISMATCH, CONFLICT or PROVIDER_ACCEPTED_UNVERIFIED and reconcile before retry. Use idempotency and revision/conditional-write protections; do not overwrite concurrent edits or duplicate side effects. Privileges and policy remain separate from checksums.
11.4 Cost controls MUST discourage repetitive full downloads, duplicate source discovery and pointless preflight. Essential security review and targeted readback remain permitted. Validate a successful one-write verified receipt, checksum mismatch, missing-checksum fallback, no-independent-proof status, wrong-ID rejection, concurrent-edit collision and replay detection. Draft text is not an active gate.

CEO VERIFIED-SAVE ACKNOWLEDGMENT LADDER — 2026-11-02 UTC (DRAFT ONLY)
RFC-AI 38 now defines one ordered storage-interface response: (1) independently received expected byte count and SHA-256, (2) authoritative provider commit, (3) correct file ID and destination, (4) independently stored content checksum, (5) correct revision and authorized operation. Short-circuit failed/unknown checks and retry only when safe; ambiguous commits require reconciliation. Do not send repetitive full reads after a VERIFIED receipt. This is a proposed interface contract, not evidence of implementation.


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: Assertions of authority and local command success were confused with real scope-controlled authorization.
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-32-UTC: Any current UTC datetime, timestamp, deadline, source-freshness comparison, expiry, or chronological identifier MUST obtain current time through GetUTCDateNow() or its approved typed Time Interface result. AI workers and application code MUST NOT read a host local clock directly for corporate decisions. The Time Interface owns actual synchronization, drift detection, freshness evidence and explicit uncertain-clock handling; a stored expiration alone never proves clock correctness. This is a future design obligation, not an implemented service.

MUST-32-01: MUST combine direct execution-boundary enforcement with later evidence-based investigation and corrective learning; universal enforcement need not be real-time.
MUST-32-02: MUST investigate patterns indicating unhealthy/violating behavior even where direct prevention did not trigger and design appropriate future control.
MUST-32-03: MUST distinguish worker identity from authenticated session, role and exact authorized operation; the enforcement Interface validates independently.

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: Enforcement MUST consult independently observed recent action evidence; forbid evidence laundering from worker-authored data. At the actual protected boundary, revalidate authorization, assignment revision, worker epoch, destination and provenance.
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 AMENDMENT 2026-11-03 — COMPLETE EFFECT-BOUNDARY AUTHORIZATION
REQ-AI-32-BOUNDARY-001: Every protected effect MUST bind authenticated human principal and delegation, worker session/workload identity, exact typed target and operation, governing source/policy revision, current assignment epoch, relevant expiry and provider entitlement. Chat text, trace IDs and context snapshots MUST NOT grant rights.
REQ-AI-32-BOUNDARY-002: Enforce every actual mutation path: cloud connector/API, browser, shell/root, storage mount, publisher, scheduled worker, and privileged recovery. Any uncovered route makes enforcement PARTIAL, not universal.
REQ-AI-32-BOUNDARY-003: Privileged recovery MUST be separately authenticated, narrowly scoped, independently logged and revoked when no longer required; remove temporary doas only AFTER tested replacement. A denied route MUST NOT be circumvented through a weaker route.
REQ-AI-32-RECEIPT-004: Effect-boundary rechecks MUST cover current authorization, target, owner epoch, source revision, and independent provider result; a permit alone is not a completed business outcome.

DESIGN CORRECTION AUTH-02 — Real authorization across every mutation boundary
RATIONALE: A broker rejection is ineffective if a shell, root privilege, direct cloud connector, browser session or sync mount can reach the same effect.
REQUIRED FUTURE BEHAVIOR: A protected operation MUST carry a typed resource class/ID, specific effect, authenticated worker/session/workload principal, authorized human delegation and revision, current assignment owner epoch, expected object revision, permission scope and expiry. The future Standard MUST enumerate every actual effect path—including scheduled tasks, storage mounts, provider APIs, shells, browsers and emergency administration—and attach the decisive check to each real boundary. An unmediated route forces CONTROL_COVERAGE=PARTIAL. Temporary emergency authority requires separate custody, revocation and a tested replacement before removal, never a model-authored self-permit.
ADVERSARIAL DESIGN ACCEPTANCE: Deny a synthetic mutation then attempt all enumerated alternate paths; every denied route refuses the actual provider effect. Test an authenticated request with a resource ID of the wrong type; deny before execution. Audit all unenumerated routes as OPEN.
SCOPE: Proposed RFC design, NOT deployed control; technical HOW belongs to the designated Standard/Interface.