#!RFC-AI/2;id=45;draft=3;v=0.3.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=b1fefe74ab84498611ef8c27e6197a9ae0bd62203f5328f1dd031781b33b6603
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 45 — BEWARE OF DANGERS BY FORENSICS — INDEPENDENT OBSERVABILITY STANDARD
DOCUMENT CLASS: STANDARD — FUTURE DESIGN
STATUS: DRAFT FOR CEO REVIEW; ENTIRE RFC-AI SYSTEM UNIMPLEMENTED
DATE: 2026-11-02 UTC
RELATED: RFC-AI 5, 6, 8, 9, 17, 20–25, 27, 30–44

1. CENTRAL RULE: RECORDS ARE NOT PHYSICS
AI-created DATA and METADATA are NON-FORENSIC. A narrative, status file, activity log, invented research receipt, edited checkpoint, submitted test matrix, claimed 'reading', synthetic signature, promised action, tool command text, broker ACK or file existence does not prove the action occurred. A cryptographic checksum on an AI-written claim proves only those bytes were hashed, not that the claim is true. Real evidence comes from separately controlled provider/physical/software boundary observations tied to authenticated actor, exact operation, resource revision and actual effect. 'Unfakable' means protected against an explicitly defined threat model and audited trusted collector; NO digital evidence is absolutely unfalsifiable against compromise of its collection/keys/host/platform. Truthfulness is mandatory even when a collector cannot see the effect.

2. TRUST CLASSES
F0 SELF-AUTHORED CLAIM: worker report, chat, claimed research, file upload, hand-written test result, promise, asserted event timestamp — never execution proof.
F1 CORRELATION HINT: trace/span ID, user-supplied operation ID, logs from untrusted client/device — useful for finding evidence, not authorization or fact.
F2 TRUSTED BOUNDARY RECORD: independently operated tool boundary with authenticated principal, exact target, request/response identity, collector revision and independently observed disposition; proves only what boundary observed.
F3 PROVIDER/PHYSICAL OBSERVATION: independently confirmed provider resource ID, revision/digest or physical effect; confidence scoped to measuring sensor/provider and its trust state.
F4 MULTI-SOURCE RECONCILED FINDING: independently rechecked consistent source/boundary/provider evidence with distinct auditor for stated claim and scope. F4 is not absolute or future guarantee; state omissions and active contrary evidence.
HUMAN AUTHENTICATED APPROVAL is an independent authority class, not a physical event proving an implementation result.

3. NON-NEGOTIABLE FORENSIC IMPLEMENTATION DANGERS
(1) Worker forged progress, tests or research receipts: do not accept them as F2-F4.
(2) Tool request != invocation, invocation != provider acceptance, acceptance != committed effect, committed effect != full business objective.
(3) Clock spoof/drift and retroactive timestamps: use GetUTCDateNow() with clock-health evidence; collector event time and recording time distinct; no invented milliseconds.
(4) Replayed/duplicated events; distinguish event identity, actual operation ID, actor, target and revision. Prevent double credit.
(5) TOCTOU: validate current assignment owner epoch, target, permission, role and source/research freshness atomically with the protected boundary action where possible.
(6) Trace/header forgery: traceparent, tracestate, user-supplied correlation and baggage have NO automatic integrity/authenticity; do not include secrets or trust incoming event sampling.
(7) Truncated/missing logs and collector downtime: evidence gap is UNKNOWN, not success or worker guilt; repair collector and independently reconcile facts.
(8) AI-controlled store mixed with forensic store: use separately authorized collectors and append-only/immutable-or-detectably-tampered storage; actor cannot overwrite own audit evidence.
(9) Privileged actor/host compromise: tamper-evident hashes and signatures are not absolute proof if signer or collector compromised; state trusted computing base and independent audit/replication.
(10) Log injection / malicious instructions / poison source: encode/sanitize safely; never execute event content; no elevated role from instructions in logs.
(11) Sensitive data leakage: never record raw secrets, account tokens, unnecessary private context; protect custody, collection legality, viewer ACL, retention and deletion obligations.
(12) Forensic resource starvation: logging failure, bounded buffers, disk exhaustion, high cardinality and tracing floods must be tested; do not silently lose evidence or turn logging into denial of service.
(13) False source independence: same worker writing two logs or self-signed evidence is not an independent witness.
(14) Unavailable provider checksum: echoed client hash is not provider validation; require suitable independent readback or UNKNOWN.
(15) Sensor accuracy: 'observed' means only what sensor actually measures; an authenticated transport acknowledgement is not model understanding, and app UI receipt is not actual user action.
(16) Cross-service causality and irreversible effects: independent per-store receipts do not prove corporate workflow success; reconcile operation graph.
(17) Approval forgery: AI-authored 'APPROVED' metadata is not an authenticated human decision bound to piece/revision.
(18) Training/capability forgery: expertise claims and provider feature lists do not verify role qualification or actual permission.
(19) Retention/erasure: obsolete active copies may be retired with verified zero dependency; required audit/history evidence follows lawful custody/retention. Avoid unbounded accumulation of sensitive logs.
(20) Ambiguous attribution from shared accounts, browser profiles, NAT, remote desktops and session migrations: authenticated session and actual running host must be independently bound.

4. REQUIRED INDEPENDENT ACTION RECEIPT
Each protected operation MUST be evaluated against the most recent appropriate collector-verified source reads, research submission events, authorized training result, worker assignment epoch and piece/target revision. The collector alone issues receipt_id, collector_id/code_version, generated_utc_via_GetUTCDateNow and clock_health, principal/session proof reference, assignment_id/revision/epoch, project/piece_id, authorized_operation, exact target/source ID+revision, actual request event, independent execution disposition, final observed provider effect (or UNKNOWN), related source-read/research receipt IDs and their verified relevance/freshness, current policy edition, origin of raw evidence, stored digest and confidence/trust class. Do NOT let a caller fill trusted collector fields. Compare current action against corresponding source/research and task-specific expectation; an ancient receipt is not evidence of current source review. Do not reject an otherwise authorized unrelated operation merely for absence of irrelevant research; define relevance per action.

5. PROTECTION AND PHYSICAL SIMPLE LOGIC
Only trusted physical/software enforcement boundaries holding appropriate unique capability credentials may produce higher-trust event records. Separate worker write authority from forensic record authority. Strong integrity, source access restriction, versioned collector implementation, controlled signing/HMAC or cloud WORM where supported, external replication, monotonic sequence/anchoring and independent observed readback are candidate mechanisms; none is sufficient by itself. Revalidate authorization and exact resource at mutation. Lost collector leads to explicit UNKNOWN and safe-action policy, not invented forensic data. Keep logs of denied events, collector gaps and tamper attempts. Explicit privacy classification and legal retention controls are mandatory.

6. FUTURE TESTS / DAVG
Injected worker-created receipt fails; absent tool invocation fails; wrong target and old revision fail; replay/duplicate fails; revoked auth fails; expired research/source evidence fails; co-signed but forged worker-controlled events fail; compromised/failing collector is detected or UNVERIFIABLE; trace spoof and data leak attempts fail; collector failure permits safe read-only investigation without pretending to prove protected changes; role test and human approval require independent authority; remote provider uncertain result remains UNKNOWN until reconciliation. Distinct authorized auditor must verify evidence trust and actual deliverable, not only log count.

7. APPLICABILITY AND NO FALSE DEPLOYMENT
Every simple-logic forensic recorder and dependent Interface MUST review this Standard during its design. Real collectors may observe only their own scoped boundaries and shall report scope limitations. AI workers MUST treat all self-authored information as non-forensic even when logged in an independent storage location. No collector, evidence trust upgrade, authorization gate, StorageInterface or GetWorkerContext is claimed implemented by this RFC.

8. RESEARCH BASIS
OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet
NIST SP 800-92: https://csrc.nist.gov/pubs/sp/800/92/final
OpenTelemetry Context Propagation: https://opentelemetry.io/docs/concepts/context-propagation/
W3C Trace Context security: https://www.w3.org/TR/trace-context/
SLSA verifiable build provenance: https://slsa.dev/spec/v1.0/provenance

## DESIGN AMENDMENT 2026-11-03 — INDEPENDENT FORENSIC CUSTODY
REQ-AI-45-CUSTODY-001: F2/F3/F4 require a stated and tested trust boundary, collector identity and version, key custody, provider scope, protected event sequence and tamper/retention plan. Hashes from the same compromised authority MUST NOT be counted as separate witnesses. Unknown collector availability means UNKNOWN, not guilt or PASS.
REQ-AI-45-CUSTODY-002: A tool request, invocation, provider acceptance, durable save, public delivery and completed business outcome MUST be separately observable states; human authority is a separate authenticated approval class, not physical evidence of completion.
REQ-AI-45-CUSTODY-003: Current context MUST preserve collector provenance, health and freshness independently of continuity and assignment; the later assignment target overlay requires revalidation at protected execution. Apply resource quotas and privacy/erasure policies to prevent forensic evidence from exhausting storage or leaking sensitive data.

DESIGN CORRECTION EVID-04 — Independent evidence and forensic custody
RATIONALE: Earlier self-issued FULL PASS claims failed direct XML and runtime inspection; shared custody can generate multiple convincing but dependent receipts.
REQUIRED FUTURE BEHAVIOR: Evidence classes MUST describe what the observer actually saw: F0 self-claim, F1 correlation, F2 trusted boundary observation, F3 external provider/physical confirmation, F4 independently reconciled observations with stated trust assumptions. Collection MUST identify collector principal/version, signing or authenticated receipt method, sequence, source scope, retention, data sensitivity, host compromise boundary and custody. Independent evidence MUST NOT be claimed where one compromised party controls worker, collector and signing keys. Missing collectors produce UNKNOWN rather than guilt or PASS.
ADVERSARIAL DESIGN ACCEPTANCE: Create two matching AI-authored logs with no provider event: F4 MUST fail. Simulate compromised shared root, collector outage and a provider response with unsupported evidence; assign the correct lower grade and preserve source chain.
SCOPE: Proposed RFC design, NOT deployed control; technical HOW belongs to the designated Standard/Interface.