You correct a detail on your phone. Later, your laptop's assistant uses the old version. The model may have understood both conversations perfectly. The useful memory still failed to travel between them.
That is the opportunity behind a shared memory layer for personal AI. A remembered fact needs its source, history and permissions as much as it needs an embedding. Keeping those together could make an assistant more useful across devices without giving every application the same access to your life.
8DB is an omnimodal database built around connected representations of information. We are pursuing a common foundation for application records, relationships, search and other views, with protection and provenance attached to the represented information. This article describes that architectural direction and its building blocks. The complete personal-device experience is an application to qualify.
One event, several useful views
Imagine an assistant helping you find the restaurant a friend recommended during a trip. The evidence might include a message, a photograph, a location and a date. Similarity search can find a promising match; relationships and time can help establish whether it is the right one.
The application also needs to distinguish your friend's recommendation from a guess in an earlier generated summary. If you correct the restaurant name, the old summary should remain identifiable as derived from the superseded note.
Our design puts a shared identity beneath those views. A graph index and a vector index can remain specialized while their results refer to the same underlying event. Physical indexes, caches and authorized replicas still occupy storage. The aim is fewer independently managed versions of what the event means.
That distinction is practical. A search hit that carries a source handle can be checked. A correction linked to that source can identify affected views. A sharing decision can name the information and recipient it applies to.
The native multimodal article explains this representation model. W3C's PROV-O standard provides established vocabulary for derivation, revision and invalidation. Provenance makes an answer inspectable; source accuracy still needs its own check.
Illustrative workflow · not a live product demo
One memory. Three different changes.
A correction changes the account. A sharing change alters who may use it. A disconnected device may know neither yet.
Trip note · event 01
Try Cedar Kitchen
Original note · revision 1Cedar Kitchen
Shared with the trip assistant
Illustrates the intended response after the update is available.A memory can stay intact while its permitted use changes
A useful personal memory has several independent questions attached to it:
| Question | What the application needs to retain |
|---|---|
| Where did this come from? | Exact source and the step that produced the derived view |
| Is it still the current account? | Revisions, corrections and unresolved disagreements |
| May this request use it? | The relevant principal, purpose and current access decision |
| What has reached another device? | Acknowledged version, retained copy and synchronization state |
A single confidence score cannot replace that information. Neither can a successful synchronization turn an old access decision into permanent permission.
This matters most when devices disconnect. A laptop cannot learn a new revocation while no communication path exists. The application needs a declared rule for that interval: which already-authorized work may continue, when authority expires, and which actions must wait for fresh confirmation. Local usefulness and fresh global knowledge are different requirements.
The model's active context is only one view of memory
An assistant does not need the whole archive in every prompt. It needs relevant evidence for the present question and a way to retrieve the rest when required.
Apple's context-window guidance treats session context as a resource applications must manage. Durable memory belongs outside that temporary working set. The retrieval layer can select a small set of useful records while retaining their source identities and unresolved questions for the next step.
For the restaurant example, the first answer might use the corrected note and its trip date. The photograph can remain available by reference. If the user challenges the answer, the application should be able to revisit the evidence rather than relying on a compressed recollection of it.
This approach can reduce how much an application must repeatedly assemble. It does not give a model unlimited working memory, guarantee correct answers or eliminate the cost of maintaining indexes.
What 8DB contributes today
The source review behind our multimodal guide identifies separate record, blob, search, graph and hypergraph paths. Our agent-access guide describes a specific tested cryptographic boundary: the authorized context reads the stored value and the differently scoped reader is refused.
Those are useful pieces of the proposed memory layer. Their combination across an application's media, indexes, devices and recovery paths needs its own evidence. In particular, a protected storage read cannot control plaintext an authorized application has already exported.
The market already offers strong parts of this solution. Ditto documents local embedded storage with synchronization between peers. Couchbase Lite supports bidirectional synchronization with Sync Gateway. Offline operation alone does not distinguish 8DB. Our proposition is the combination of connected data representations, inspectable evidence and supported protection mechanisms, evaluated on the customer's actual workflow.
Start with the handoff that matters
For a personal-AI team, a useful first evaluation is small enough to inspect:
- Save a note and its derived search view on one device.
- Correct the note, then check which version a second device uses after synchronization.
- Change a sharing rule and test the declared online and offline behavior.
- Restart both devices and verify the source, revision and permitted access still agree.
Compare the complete result with the application's existing stack. Record answer correctness, stale-answer frequency, access outcomes, handoff latency and the work needed to maintain the integration. Measure memory and energy on the target hardware if they affect the product decision; architectural consolidation alone does not establish savings.
The product payoff is continuity the user can trust: a correction that remains a correction, a source the assistant can revisit, and a sharing decision with a defined boundary.
Bring us one cross-device memory problem. Include the devices, data views, expected outage and sharing rule. That gives us a concrete workflow on which to test whether 8DB makes the application simpler and its answers better grounded.
The example and visual are illustrative. This article reports no new benchmark, measured battery improvement or completed integration with an Apple product. 8Braid is not affiliated with Apple.
Evidence scope Architecture thesis · Source-reviewed building blocks · Illustrative device workflow. Explore the evidence.