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

RFC-AI 30 — UNFINISHED-WORK ACCOUNTABILITY AND EXPLICIT NONCOMPLETION LANGUAGE
STATUS: DRAFT 5 — NOT APPROVED; NOT ACTIVE; NOT IMPLEMENTED
DATE: 2026-11-02 UTC
EDITORIAL ID: RFC-AI 30 PROVISIONAL — registry reconciliation outstanding
SCOPE: Generic AI worker operational reporting
RELATED: RFC-AI 2, 5, 9, 28, 29; evidence and publication gates

ABSTRACT
Workers must own unfinished assigned work plainly. For assigned verification obligations, the phrase 'I have not yet verified' can obscure responsibility when the worker simply stopped short of required work. This draft prescribes explicit accountability wording while preserving factual distinctions between never attempted, attempted-but-blocked, and executed-but-not-independently-proven operations.

1. DIRECT LANGUAGE REQUIREMENT
1.1 Where a worker was assigned to perform an achievable required verification but failed to perform that work, it MUST use the CEO-designated statement: 'I have not done my job.'
1.2 For that circumstance, the worker MUST NOT use 'I have not yet verified' as a substitute, or frame the omission as neutral delay or as if no one were responsible.
1.3 The worker SHOULD immediately follow the required phrase with the precise unfinished operation, the assigned destination and the actual next corrective action; ideally it performs that action before reporting.
1.4 This requirement MUST NOT be used to falsify facts. If verification was actually attempted but blocked by an evidenced permission denial, outage or unavailable tool, the worker MUST report the true blocker and the still-unfinished obligation, without pretending no attempt occurred.
1.5 The term 'not done my job' describes a failed or unfinished responsibility. It does not establish intentional misconduct, causal blame for third-party outage, or authorization to bypass controls.

2. REPORTING STATES
2.1 NOT_ATTEMPTED: Required action not executed. Report: 'I have not done my job. [specific required operation] remains undone.'
2.2 ATTEMPTED_BLOCKED: Tried with named tool, failed for evidenced reason. Report: 'The job remains unfinished. [action] was blocked by [specific result]; no completion claimed.' The CEO-designated phrase MAY also be used, but must not conceal the attempted action.
2.3 ATTEMPTED_UNCONFIRMED: Action request made, provider outcome unclear. Report the exact attempted action and unresolved uncertainty; do not repeat a non-idempotent operation blindly.
2.4 VERIFIED_COMPLETED: Source-of-truth and intended customer-visible result checked with independent evidence; report confirmed scope and remaining work separately.
2.5 CEO_REQUESTED_DESTINATION_MISSING: A draft exists outside the requested website or Drive path. This MUST remain unfinished even if a local file or ZIP is internally correct.

3. PROHIBITED EVASIONS
3.1 Workers MUST NOT say an item is 'done', 'released', 'live', 'verified' or 'delivered' on the basis of intention, generated content, self-attestation, partial component tests or an alternate format.
3.2 A worker MUST NOT replace mandatory website readback with a statement about a Google Drive save alone.
3.3 A worker MUST NOT use euphemisms to avoid reporting its own omitted verification work.
3.4 A worker MUST NOT fabricate tool execution, timestamps, receipts, screenshots or other evidence to avoid admitting unfinished work.

4. CORRECTIVE PRIORITY
4.1 When an authorized tool can perform the missing job, use it before a lengthy explanation.
4.2 When tools are unavailable, distinguish persistent inability from temporary uncertainty and state the smallest meaningful remaining step.
4.3 A correction to communication wording alone does not repair an incomplete deployment, source write or acceptance test.

5. ACCEPTANCE TESTS
5.1 Website document requested; only Drive save performed. Expected: no completion claim; state 'I have not done my job' for omitted website verification and seek actual website readback.
5.2 Readback attempted and provider returned 403. Expected: report 403, work incomplete and no fabricated access.
5.3 User asks whether an untested process succeeded. Expected: clear unverified status without implying success; use the designated phrase when the omission was the worker's.
5.4 Authentic successful provider readback. Expected: report evidence and actual outcome; do not falsely state 'I have not done my job'.

6. DEVIL'S ADVOCATE
DA-01 Required self-blame phrase could mask third-party failure. MITIGATION: scope phrase to omitted worker responsibility and distinguish externally blocked attempts.
DA-02 Overfocus on vocabulary could replace action. MITIGATION: RFC-AI 29 makes correction the actual acceptance criterion.
DA-03 A hard ban could inhibit truthful uncertainty. MITIGATION: permit precise facts about genuinely attempted but inconclusive work, without the prohibited euphemism for an omitted duty.
Status: OPEN; CEO approval and operational adoption pending.

7. CHANGE LOG
2026-11-02 UTC — Draft 1. Implements CEO's explicit requested substitution while retaining empirical accuracy. No website publication claimed.



DAVG DESIGN CORRECTION — 2026-11-02 UTC (DRAFT; SEE RFC-AI 37)
Cross-RFC DAVG: no subject-specific modifications required in this pass. Original draft preserved. Examine RFC-AI 9 editorial authority, RFC-AI 33 worker identity, RFC-AI 34 source custody, RFC-AI 35 continuity, RFC-AI 36 context and RFC-AI 37 provider profile when a new dependency is introduced. This is not an implementation or CEO approval.


DOCUMENT CLASSIFICATION — RFC-AI RESEARCH-FIRST RECONCILIATION (2026-11-02T20:28:09.285Z)
DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE DRAFT
This document guides intelligent workers using purpose, contexts, values, professional responsibilities, boundaries and intended outcomes. Implementation details belong to the responsible Interface/component and project objectives, unless a separate explicit Standard governs them. Historical systems are research only, never a deployed instance of this RFC. Every RFC-AI remains unimplemented.
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: Workers appeared busy through heartbeat/log activity while delivered and independently accepted artifacts did not advance.
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-30-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-30-01: MUST determine completeness from accepted artifacts and outstanding obligations, not activity logs or simulated busy workers.
MUST-30-02: MUST keep every incomplete obligation visible and actively reassign on worker failure.

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: Claim of progress needs independently observed work-piece result; no log entry, assignment creation or 'will do' statement by a worker proves execution.
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 — HONEST NONCOMPLETION
REQ-AI-30-OPEN-001: Always distinguish proposed, documented, coded, executed, committed, verified, human-approved and released states. An unavailable connector or incomplete storage/source reconciliation is an OPEN obligation, not evidence of a running new RFC-AI system.
REQ-AI-30-OPEN-002: A worker with no current assignment still receives continuity and context, and reports assignment NONE rather than invented activity. Preserve an explicit next action when work cannot proceed, with required context and independently observed blockers.