Phase 2: Audit dashboard (two-tier visible: real-time feed + chain anchor)

[hanwencheng]

Context

The M1 parent UI (#110) is demo-grade — enough to show Act 3 (revocation) live. The M2 audit dashboard graduates it to production-grade: parents inspect what happened, vendor admins debug disputed events, and regulators verify the audit chain against on-chain Merkle proofs.

This is the surface where the "two-tier audit" (#109) and "deterministic denial" pieces become legible to non-technical users — the parent doesn't see Merkle proofs, but they DO see "your device tried to send a message at 11pm on Tuesday and was denied."

Without this, the audit feed is technical-only and doesn't carry the consumer value prop.

Scope (M2)

Filtering + slicing

• Filter audit feed by actor (which device), time window (custom + presets: last hour / day / week / month), event type (cap.mint, permission.check, memory.read/write, revocation, denial), namespace (personal/family/work/travel)
• Search by free text (matches event params + audit-row metadata)
• Saved-view feature: parent can save "all denials last week" for one-click recall

Two-tier visibility

• Side-by-side panel: Tier 1 real-time feed (from Phase 1: Two-tier audit wiring (real-time off-chain feed + 2-min on-chain anchor) #109's SSE) + Tier 2 on-chain anchor batches with their Merkle roots
• For each event, show "anchored at HH:MM" badge once the on-chain batch lands
• Click any event → detail modal showing the full envelope + Merkle proof path to the latest anchor

Export

• CSV — for parent-side spreadsheet review
• JSON — for developer / vendor admin investigations
• Regulator-friendly PDF — pre-formatted report with header (actor identity, time range, total event count), event log with timestamps + types + outcomes, footer with Merkle root verification block. PIPL / CAC audit log format compatible.

Tamper-evidence verification

• Download Merkle proof for any event — JSON blob with the path from event to anchored root
• "Verify against on-chain anchor" button — recomputes the proof against the live on-chain root via chain RPC, shows green checkmark or red mismatch
• Documents the verification math in a footer link for skeptics

Anomaly detection (basic)

• Unusual spend: a payment cap-mint > X stdev above recent average for that actor
• Unusual time-of-day: device activity outside the actor's usual hours
• Repeated denials: ≥N denials in a 24h window flagged for parent attention
• All anomalies surface as inline UI badges + push-notification opt-in (parent enables in settings)

Out of scope (defer)

• Cross-actor / cross-family views (M4 with delegation depth)
• Vendor-admin views of parent-side audit data (M3 — privacy-bound; we don't expose parent-side data to vendors by default)
• LLM-driven natural-language audit query ("show me when the toy refused a request last week") — M4 with delegation work
• ML-based anomaly detection (M4 — basic rule-based now)

Acceptance criteria

• Parent can answer "what did my AI toy do last night?" by opening the dashboard, filtering to last night's time window, and seeing a clear event log within 10 seconds
• Parent can filter to "payment events only" and export a CSV — verified end-to-end with at least 100 events of mock data
• Vendor admin can pull up a contested event (claim: device made an unauthorized payment), download the Merkle proof, verify against the on-chain anchor, and see the verification result (pass or fail)
• Regulator-friendly PDF export passes a sanity-check against PIPL Article 22 / CAC audit log requirements (footer block contains the Merkle root + chain explorer link + verification math)
• Basic anomaly detection fires correctly on synthetic test data (unusual spend, unusual time, repeated denials)
• Mobile-responsive: works in iPhone Safari + Chrome Android; Lighthouse mobile score ≥ 90 for Performance + Accessibility

Risks

Risk	Mitigation
Regulator PDF format requirements vary by region (PIPL vs GDPR vs CCPA)	M2 targets PIPL (CN-region vendors first); GDPR / CCPA in M3 when EU / US pilots land
On-chain Merkle verification is slow from a phone	Verification runs server-side; client only displays result + signed verification proof
Anomaly detection false-positives annoy parents	Tunable threshold per actor in vendor settings; default-off until parent enables
Tier 2 anchoring lag (2 min) makes new events appear "unverified"	UI shows "Pending anchor" badge with the next-anchor-ETA countdown; parent sees the system is working

References

• docs/spec/plans/milestones-roadmap.md §3 (M2 scope)
• docs/research/agent-iam-strategy.md §3.2 (two-tier audit correction)
• docs/arch.md §15 (audit framing)
• Phase 1: Two-tier audit wiring (real-time off-chain feed + 2-min on-chain anchor) #109 (Two-tier audit wiring — data source for this dashboard)
• Phase 1: Parent-control web UI (mobile-responsive) for v0 demo #110 (M1 parent UI — this issue extends rather than replaces; v0 surface graduates here)
• Phase 2: Vendor onboarding portal (tenant tokens + billing + attributed devices) #113 (vendor portal — vendor admins access via their tenant role)

Effort

~1-2 weeks. Sequencing:

1. (Days 1-3) Extend Phase 1: Parent-control web UI (mobile-responsive) for v0 demo #110's UI with filter / time-window / search
2. (Days 3-5) Two-tier side-by-side visualization + per-event Merkle proof download
3. (Days 5-8) Export pipelines (CSV, JSON, PDF with regulator template)
4. (Days 8-10) Tamper-evidence verification UI + on-chain RPC integration
5. (Days 10-14) Basic anomaly detection + mobile polish + acceptance tests

Pickup notes for the next agent / developer

• Build on top of Phase 1: Parent-control web UI (mobile-responsive) for v0 demo #110's UI codebase; don't fork
• The SSE feed from Phase 1: Two-tier audit wiring (real-time off-chain feed + 2-min on-chain anchor) #109 is the data source — extend it to support filter params server-side so the client doesn't pull megabytes of events
• For PDF generation: use a headless-browser approach (Puppeteer / Playwright) — Markdown → PDF tools tend to produce ugly regulator output
• The PIPL audit log format spec is sparse; copy the structure of a known-good Chinese fintech audit log (operator advice: check with a regulatory consultant before signing off)
• Anomaly thresholds: start with stdev-based detection on the trailing 30-day baseline. Don't ship ML in M2.
• Watch for: parents will trust the audit dashboard. If we display a false-positive denial they'll lose confidence. Prefer false-negatives (miss an unusual event) over false-positives (alert on noise) for anomaly thresholds.
• Use the /agentkeys-issue-create skill for follow-up issues (e.g., per-region regulator format variants)