Designing an On-Device Personal Memory System

EchoWeave is a design proposal, not a shipped product or working prototype. It was created as a sample planner output for the DreamForge delivery concept and remains a P2 idea awaiting technical and market validation.

The useful question is therefore not “what does EchoWeave do?” It is: what architecture and evidence would be required before a product could responsibly synthesize health, calendar, messages, photos, and location into personal narratives?

Product thesis and explicit non-goals

The thesis is that a person may recover useful context from fragmented personal data without sending the raw corpus to a cloud inference service. The first narrow use case would be a private weekly review that cites its sources and asks for correction.

The first version should not diagnose health conditions, infer another person's private traits, automate consequential decisions, monitor family members, or claim an objective account of a life. A generated narrative is a fallible summary, not memory and not truth.

The proposed single-device architecture

OS-approved data connectors
        │
        ▼
Consent & purpose gate ──deny──▶ no ingest
        │
        ▼
Normalizer + provenance ledger
        │
        ├──▶ encrypted event store
        ├──▶ local search index
        └──▶ derived entities/links
                    │
                    ▼
          bounded retrieval query
                    │
                    ▼
          on-device narrative model
                    │
                    ▼
        citation + safety verifier
                    │
                    ▼
          private review interface

Start on one device. Encrypted peer-to-peer sync and a home node appeared in the original concept, but they multiply identity, conflict, deletion, backup, and key-recovery risks. They should not enter the MVP until the single-device boundary is demonstrably useful.

Data model: events first, narratives last

Every ingested item becomes an immutable source event with:

• connector and source identifier;
• event time and ingest time;
• data classification and permitted purposes;
• content hash and local encrypted reference;
• people or entities only when the user permits extraction;
• derivation links to embeddings, graph edges, summaries, and narratives.

The derivation graph is essential. Without it, deleting a message removes the source while leaving its embedding, extracted facts, and narrative claims behind.

Consent must be granular and reversible

Decision	User control	System evidence
Connector access	Select account, data categories, and time range	OS grant plus local consent record
Purpose	Search, weekly review, or pattern suggestions separately	Purpose checked on every retrieval
Sensitive categories	Exclude health, precise location, or named people	Policy filter before indexing and generation
Retention	Keep source and derived data for different periods	Scheduled deletion report
Action	Reflection only by default; automation separately enabled	Action-specific approval receipt

Revoking a connector stops future ingest. Deletion is a separate operation: remove the source, traverse the derivation graph, delete or recompute affected artifacts, clear caches, and record completion without retaining the deleted content.

The privacy boundary is larger than the model

“The model runs locally” does not mean “the product is private.” Exposure can occur through:

• mobile backups and diagnostic logs;
• lock-screen notification previews;
• keyboard, accessibility, screenshot, and screen-recording services;
• model or connector updates;
• shared-device access and weak local authentication;
• peer sync, crash reporting, and analytics;
• prompt injection embedded in messages, documents, or calendar text.

The design should use per-device encryption keys protected by the OS keystore, minimal logs, no raw-content analytics, authenticated updates, explicit export, and a local network deny rule for the inference process. A privacy claim is a tested system property, not a model placement diagram.

Narrative integrity: the overlooked risk

A personal memory system can be harmful without leaking data. It can create false coherence, overemphasize what is digitally visible, misattribute another person's words, or turn a model's inference into a remembered fact.

Every narrative should therefore:

1. link each factual sentence to visible source events;
2. label inference and uncertainty separately;
3. offer “wrong,” “not useful,” and “do not use this source” controls;
4. avoid claims about third parties unless explicitly supported and permitted;
5. never silently write generated statements back as source memories.

The product should optimize for correction, not persuasion.

Resource budgets are product requirements

On-device processing competes with battery, heat, storage, and foreground responsiveness. The MVP needs measured budgets rather than a vague promise that quantized models “run on phones.”

Resource	Design strategy	Release gate
Battery	Incremental ingest; heavy synthesis while charging	Daily background workload stays within a pre-registered battery budget
Thermal	Bounded generation and OS-aware scheduling	No sustained thermal throttling in the device matrix
Storage	Deduplication, retention tiers, visible quota	Quota enforcement and deletion reclaim verified
Latency	Small retrieval set; model sized per device	Interactive search and weekly summary meet separate targets
Memory	Stream ingest; load model only for scheduled work	No OS termination across supported devices

Targets should be set after a prototype baseline, not invented in an article.

One bounded user journey

1. The user enables calendar and selected photos for “weekly review,” excluding location and messages.
2. The device imports the last seven days, records provenance, and builds a local index.
3. While charging, the model retrieves a bounded set and drafts three observations.
4. The verifier removes uncited factual claims and marks interpretations.
5. The user opens the app, reviews sources, corrects one claim, and hides a photo category.
6. The correction updates the local policy; it does not train a remote model.
7. The user deletes the week. Source and derived artifacts are removed and a deletion report is shown.

Validation sequence and kill criteria

EchoWeave should advance only through evidence gates:

1. Problem interview: do privacy-conscious users want a cited weekly synthesis, or only better search?
2. Static prototype: can users understand sources, inference labels, consent, and deletion?
3. Single-connector technical spike: can one device complete the workflow inside measured resource budgets?
4. Red-team test: can hostile content, shared-device access, backup, or logs cross the boundary?
5. Small local pilot: do users correct, retain, and voluntarily return to the review?

Kill or redesign the concept if cited summaries are not more valuable than search, deletion cannot cover derived data, device budgets make use unreliable, or people feel monitored rather than supported.

Download the threat model

The threat-model CSV includes assets, trust boundaries, threat scenarios, controls, verification evidence, residual risk, and release gates.

Download the EchoWeave privacy threat model

For storage and forgetting policy, continue with AI agent memory architecture. For the delivery system EchoWeave was intended to test, see the honest DreamForge automation-boundary case study.