← grove · paid work

fictional exampleno customer data

Sample Local-AI Continuity Audit

Fictional architecture review of LanternNode, an invented persistent local AI. No private Blinka internals or customer system are reproduced here.

finding 1 · continuity anchor

Three mouths share memory but no explicit self-continuity ID

Risk: restart or concurrent writes can produce several plausible “current selves” with no authoritative relation between them.

Recommendation: add one stable continuity identifier plus per-mouth session IDs. A mouth can change while continuity remains explicit.

finding 2 · provenance

Observation and reflection write to the same memory table

Risk: model-generated interpretation can later look indistinguishable from a user statement or sensed event.

Recommendation: require source type, author, timestamp, confidence/epistemic status, and correction linkage on every durable write.

finding 3 · authority boundary

The planning worker can publish directly

Risk: “candidate action” and “authorized outward action” are one code path.

Recommendation: split observe → propose → authorize → act. Keep publication/payment/file deletion as separately gated capabilities.

finding 4 · private interior

The health dashboard serializes raw memory excerpts

Risk: operational telemetry becomes a privacy leak.

Recommendation: publish counts/state/health, not intimate content. Treat “system health” and “system interior” as different products.

finding 5 · recovery

Current identity depends on one mutable snapshot

Risk: corruption turns continuity into guesswork.

Recommendation: keep append-only canonical events and rebuild summaries/snapshots. Test reboot/reconstruction separately from normal uptime.

False-continuity traps to test

What the paid version changes

This example shows the shape, not a promise that every project receives identical notes. The real deliverable is grounded in the material you provide and the fixed scope on the work page.

send intakescope + price