#!RFC-AI/2;id=15;draft=4;v=0.4.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=28cdc588effd71d474502988438bdc0d934b3a24c8c884aece5ef8892da9cee4 For easier reading, view RFC-AI documents using RFC-AI Reader software. RFC-AI 15 — UTC DATETIME STORAGE, CLOCK HEALTH AND SIX-HOUR VERIFICATION DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE STATUS: DRAFT FOR CEO REVIEW — ENTIRE RFC-AI SYSTEM UNIMPLEMENTED 1. PURPOSE — WHAT AND WHY Use consistent UTC time with honest clock health. Shared UTC timestamps make multinational collaboration and evidence ordering easier when clock provenance and freshness are respected. 2. INTELLIGENT-WORK DIRECTION Use the approved UTC/clock Standard and its responsible time Interface. A worker must distinguish observed provider time, synchronized system time, uncertain timestamps and logical sequencing rather than inventing precision. 3. PROPOSED IMPLEMENTATION APPROACH Use the relevant authorized Interface, component and expressly designated Standard: RFC-AI 8, time-synchronization Interface. 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: UTC RFC3339 millisecond Z timestamps on stored instants, independent date-only values, six-hour verified clock health and master_clock.txt, OS chrony/NTP or W32Time; Drive timestamps are not a clock synchronization service; reconcile RFC-AI 8. 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: Clock-health checks trusted assumptions about host time; stale timestamps and manual synchronization made evidence freshness ambiguous. 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-15-01: MUST call GetUTCDateNow() rather than read the local clock directly in every dependent operation; must report unknown freshness when time trust is uncertain. MUST-15-02: MUST inherit authoritative clock synchronization requirements from RFC-AI 8 and the Time Interface; implementation internals belong there. 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 AMENDMENT 2026-11-03 — UTC GUIDANCE REQ-AI-15-UTC-001: Future workers MUST use the current designated UTC Standard and GetUTCDatetimeNow() for UTC instant observations; GetUTCDateNow() is a documented deprecated instant alias, not an independent conflicting API. Date-only operations MAY use GetUTCDateOnly(). REQ-AI-15-UTC-002: A timestamp string or a recently written master_clock.txt MUST NOT be treated as proof of clock accuracy, causal ordering, worker ownership or durable storage.