Event Graph Audit — 2026-04-28

Auditor: Socrates 🧠
Phase: 6.1 UAT
Status: ❌ Event Graph does not exist yet

1. Current Event Graph State

Finding: Event Graph is a planned Phase 6+ feature — no implementation exists

Evidence:
- Zero code references to event_graph, EventGraph, or event-graph anywhere in the Icarus codebase
- Memory note (2026-04-28.md) explicitly states: "Queued for Phase 6 sprint"
- No database table, ChromaDB collection, or SQLite schema for Event Graph
- No API endpoint for Event Graph reads/writes

Documents processed today (2026-04-28)

• icarus.db: Only grocery_list and recipe_temp_state tables — no document processing logs
• ingress_logs.db: 1 entry from 2026-04-26 (test), nothing today
• ChromaDB family_knowledge: 47 documents, all ingested 2026-04-17 via email pipeline — nothing today
• Radicale: 13 .ics files exist but all pre-UAT (test events)
• briefing_events table: Does not exist in icarus.db (table was never created by init_db)

Verdict: No UAT documents have been processed through the pipeline today

2. Existing Persistence Layers (What IS working)

3. Pipeline Flow Verification

Document → Vision extraction (qwen3-vl:8b)        ✅ Working
         → Briefing generation (llama3.1:8b)       ✅ Working
         → Family member inference                  ✅ Working
         → Calendar action buttons                  ✅ Working (code exists)
         → Radicale calendar write                  ✅ Working (manual trigger via button)
         → Event Graph write                        ❌ NOT IMPLEMENTED
         → Coordination type routing                 ❌ NOT IMPLEMENTED
         → Dashboard document visibility            ❌ WIRED BUT EMPTY (0 docs)

What's wired but unused:

• calendar_action.py — Full handler exists, creates Radicale events via callback
• briefing/generator.py — Generates action_buttons metadata with has_calendar_event flag
• documents.py — Schema for briefing_events table exists but table was never created in icarus.db
• intent_router.py — Routes Telegram group replies as calendar intents (move/cancel/add)
• pipeline.py — Document sorter classifies by family member, but no Event Graph write step

4. Critical Answers for Matt

1. Calendar events: ✅ PARTIAL

• Radicale is running (active since 2026-04-18, 13 events exist)
• Calendar add button code exists and calls create_event() → Radicale
• Caveat: Radicale not reachable on port 5233 from Python caldav client (connection refused) — may be a binding issue, though systemctl shows it's active
• Calendar events ARE created when user clicks "Add to Calendar" button
• No automatic calendar creation — user must tap the button

2. Dashboard visibility: ❌ EMPTY

• System State API serves at localhost:8001/system/state
• Telemetry shows 0 documents, 0 routing decisions
• The routing_decisions list is a hardcoded empty list: routing_decisions = [] with comment "placeholder — wire to ingress spooler"
• Dashboard is NOT connected to any document processing pipeline
• Documents processed via Telegram do NOT update the System State counters

3. Event Graph logging: ❌ NOT IMPLEMENTED

• No Event Graph code exists anywhere
• No database table for event graph entries
• coordination type classification is documented in memory but has zero code
• Phase 6.1 completion did not include Event Graph implementation
• Memory note explicitly marks this: "Queued for Phase 6 sprint"

5. Summary

The pipeline works end-to-end for calendar_event type documents:
Document → Vision → Briefing → [Add to Calendar] → Radicale ✅

But there is NO persistence layer between "briefing generated" and "user taps button":
- Briefing cards are ephemeral (sent to Telegram, not stored)
- briefing_events table schema exists but was never initialized
- No document log exists showing what was processed
- No Event Graph for coordination-type documents
- System State dashboard shows zeros — not wired to pipeline

Bottom line: UAT documents are NOT persisting. They flow through the vision/briefing pipeline and hit Telegram, but nothing is logged, stored, or queryable afterward.