Implemented foundations
Selected record ingestion, encrypted storage, local retrieval, and early console, CLI, and MCP surfaces.
ARCHITECTURE · INSPECT THE FLOW
Memory in motion.
Boundaries in view.
Follow one fictional travel record from a selected import through local storage and search to a separately configured off-device handoff. This interactive model distinguishes implemented capability from research and proposed layers.
Private continuity, with boundaries
A clear answer
Which parts of SEAL work today?
Selected record ingestion, encrypted storage, and local retrieval are implemented early foundations. Policy, assistant grounding, and some recipient paths are partial; universal sync and broad orchestration remain future work.
Read SEAL’s visionVISION / PROPOSED SYSTEM MODEL
Coordination that stays accountable to people.
A future direction, not a description of current integrations: chosen context would move between tools only across visible, purpose-bound boundaries, with consequential decisions returned to people.
People remain able toinspect scope·approve consequential actions·pause future access·change tools
ALPHA TODAY · IMPLEMENTED, PARTIAL, AND OPEN
What exists—and where the edges remain.
Selected imports, encrypted record storage, and local retrieval are implemented early mechanisms. Policy, grounding, and some recipient paths remain partial; universal synchronization and broad orchestration are future work.
Partial or under research
Selective disclosure, policy enforcement, audit evidence, assistant grounding, and some configured network paths.
Future work
Universal app synchronization, broad agent orchestration, continuous device context, and institutional integration.
LOCAL / DEVICE BOUNDARYOFF-DEVICE ONLY WHEN CONFIGURED
Chosen-record ingestion, encrypted storage, and local retrieval are implemented early capabilities. Policy and audit mechanisms are partial; grounding and minimal-disclosure remain unresolved research. Local search does not itself contact a model. A configured model or storage recipient is a separate off-device path; a released handoff cannot be recalled.
IMPLEMENTEDStage 01
Source
Fictional record: “Train departs at 08:42.” A person selects an export or supported source. Only the selected record enters this example; no live account is read and no information leaves the device at selection.
Storage and recovery / SEAL technical notes
Keys stay part of the story.
SEAL technical notes describe per-record keys, XChaCha20-Poly1305, X25519 plus ML-KEM-768 device envelopes, and a 24-word recovery phrase. Security review is in progress; this is not an independent audit or a guarantee of perfect privacy.
TRUST BOUNDARY
Local derived index and audit → off-device storage / configured recipient
KNOWN LIMITS
Pattern-based redaction may miss sensitive meaning. Local audit cannot prove a recipient deleted a released copy. Security review continues, and shared information cannot be recalled.
SEAL does not currently offer universal sync, broad agent orchestration, enterprise SSO, RBAC, compliance programs, or SLAs.
Useful details
Questions, answered plainly.
Answers reflect the capabilities and limits described on this page.
Which capabilities are implemented, partial, or future work?
Selected imports, encrypted record storage, and local retrieval are early implemented foundations. Policy, grounding, and some recipient paths are partial; universal sync, broad orchestration, and institutional integration are future work.
Can a released handoff be recalled?
No. A person may pause future access or change tools, but cannot recall a copy already released. Local audit cannot prove a recipient later deleted it.