How Should a Local-First AI Knowledge Base Sync Across Devices? Sources, Embeddings, Conflicts, and Deletion

Import a scanned PDF on your phone, search for a passage offline, then have a small local model answer with a citation. That is already useful. The architectural difficulty appears when you open the same library on a laptop, edit a note on another device, or revoke the PDF entirely. Should the app synchronize the original file, OCR output, chunks, or vectors? What if the phone and laptop use different embedding models? Could a device returning from a week offline accidentally restore content you deleted days ago? And could a previously retrieved chunk still slip into the model’s prompt after its source has been revoked?

The central engineering distinction is between replicating authoritative source changes and rebuilding device-specific search capability. Source documents, access decisions, revisions, and deletion events need a verifiable replication contract. FTS indexes, embeddings, summaries, and reranking caches require separate validity and invalidation contracts. Treating an entire local AI database as one indivisible object may appear convenient at first, but creates tight coupling across model upgrades, offline conflicts, and deletion requests.

Decide what must sync before choosing a sync engine

Consider a 200-page scanned PDF imported on an iPhone. The phone stores the original, runs OCR, chunks the extracted text, creates an FTS index, and later computes local embeddings. When a macOS machine joins the library, at least three distinct operations are needed: it must receive an authorized version of the original, regain search capability using its own indexing pipeline, and resolve any concurrent edits or revocations under an explicit policy. These operations have different success conditions and should not share a single vague “synchronized” flag.

The following matrix is a proposed data contract, not a claim about what RecalAI or another application currently implements.

Object	Recommended treatment	Required boundary
Original PDFs, media, documents, user-authored notes	Replicate authorized versioned contents or encrypted objects	Stable source ID, hash, revision, scope
Source metadata, space membership, permissions	Replicate verified changes	Device identity and tenant/space isolation
Revoke/delete operation	Replicate durable tombstones or equivalent events	Replay protection, offline delivery and retirement rules
OCR output and chunks	Rebuildable; optionally transfer versioned cache	Parser/chunker versions and source revision
FTS, embeddings, ANN/vector indexes	Prefer local rebuild, or reuse only explicitly compatible cache	Model identity, dimensions, index/schema compatibility
Ranking and generation caches, ephemeral task state	Usually device-local	Must never overwrite source-of-truth records
Persistent personal memory and conversations	Separate policy and data lifecycle	Not automatically equivalent to imported reference documents

Figure 1. Replicate authoritative sources and change events; regenerate device-specific indexes. This is an engineering illustration, not a screenshot of an implemented product.

Embeddings are not inherently “unsynchronizable.” If devices use the same model and compatible vector pipeline, shipping a cache may save compute and battery. Yet identical-looking vector fields are not an interoperability guarantee: models, dimensions, normalization, chunk boundaries and index algorithms all matter. A phone with a compact embedding model and a desktop with a different one may need to rebuild independently. The choice between transferring a verified cache and recomputing it must be based on measured compute, storage, bandwidth, latency and privacy costs—not a blanket rule.

This distinction matters when a local AI application uses on-device models for different jobs. Answer-generation examples such as Gemma 3 1B or LFM2.5-2.6B should not be confused with retrieval-embedding families such as EmbeddingGemma 2 and Qwen3-Embedding-0.6B. Two devices might run the same answer model but use incompatible embedding models, vector dimensions, or chunking rules, requiring separate validation or reindexing. These are illustrative model choices for a versioning contract, not a four-model cross-device benchmark or evidence that all four have been tested in RecalAI.

The Any local-first documentation makes a useful design distinction: local writes succeed before network exchange, and its search index is derived state rebuilt on the device rather than a component of the synchronized change DAG. This is evidence of a concrete implementation, not an industry-wide requirement for every AI app. A stronger prior-art check is SQLite-Memory’s public repository, which explicitly describes synchronizing its content table while keeping embeddings and local provenance device-side, with a reindex operation after synchronization. That means “sync source content, rebuild vectors locally” is already an implemented pattern, not an XBSTACK invention. The independent contribution here is a clearly bounded, reproducible analysis of deletion propagation, FTS5 consistency, stale revision replay, and evidence validity across a proposed multi-device AI library; those fixture results do not verify the shipping behavior of SQLite-Memory or RecalAI.

A three-layer architecture: source log, materialized indexes, and AI evidence

For a personal AI library, separate the system into three responsibilities. At the bottom, an authoritative layer manages file objects, source manifests, access scopes, versions, changes and revocations. In the middle, device-local materialization performs OCR, chunking, full-text indexing, embedding, ANN construction and summaries. At the top, the evidence layer performs hybrid retrieval, reranking, evidence selection and citation validation before an answer is generated. The synchronization protocol carries source-of-truth changes. Index workers consume only sources valid for that device and revision. The answer generator must not bypass the final source validity check.

Device A: originals + SourceManifest + ChangeLog
                     |
               authenticated, versioned changes
                     v
             relay / peer transport
                     |
              authorization + deduplication
                     v
Device B: originals + SourceManifest + ChangeLog
                     |
            +--------+----------------------+
            |        |                      |
           OCR     Embeddings          revocation state
            |        |                      |
          FTS       ANN                      |
            +--------+-----------+----------+
                                 |
question -> hybrid retrieval -> rerank -> evidence selection
                                          |
                              source + permission recheck
                                          |
                                  citations + answer

Figure 2. Three-layer reference architecture showing source changes, local indexing, and citation verification across two devices. Illustrative design, not a production capture.

Two consistency objectives should be distinguished. Replica convergence means connected devices that have accepted the same valid operations eventually agree on authoritative sources and revocation state. Answer-time safety means a device must not inject an already-known revoked source into a prompt even if a stale derived index still contains its terms or vectors. The first requires a conflict-aware change protocol. The second requires a validity gate during retrieval and again immediately before prompt assembly. Neither can magically communicate a remote deletion to a device disconnected from every network.

A minimal illustrative change record could look like this:

{
  "event_id": "evt_01_example",
  "space_id": "space_example",
  "source_id": "doc_01_example",
  "operation": "revoke",
  "source_revision": 18,
  "parent_revision": 17,
  "actor_device_id": "device_a",
  "content_hash": null,
  "deleted": true,
  "key_epoch": 4,
  "schema_version": 1
}

The event ID supports deduplication; the stable source ID identifies the logical document; the source revision expresses the ordering policy; the key epoch records a key-rotation generation but is not encryption itself. An integer revision can work when a trusted coordinator allocates monotonic versions. It does not solve arbitrary concurrent writes from multiple independent devices. A real multi-writer design needs causal metadata, dependency-aware operations, version vectors, or appropriate CRDT semantics. Every operation also needs actual authentication, authorization, and anti-replay checks outside this example. No secrets or real user data belong in the sample.

Offline conflicts: timestamps and arrival order are not authority

A last-write-wins field is tempting. However, a device clock may be wrong, and the last payload to reach a relay is not necessarily the user’s newest intentional change. Collaborative notes may need causal operations, a CRDT, or retained conflict versions. An immutable or binary PDF often needs two versioned copies or an explicit user decision rather than line-level merging. Automerge’s conflict documentation is instructive: concurrent writes to the same property can retain multiple conflicting values even when a deterministic value is presented by default. Replicas agreeing on what to display is not the same as resolving the user’s business intent.

Figure 3. Document revisions, stale-replay rejection, permission-aware evidence selection, and citation re-check; example identifiers and versions are illustrative.

There are existing implementations to learn from. LocalAI’s official Chat History documentation describes server-assigned revisions, persistent conversation tombstones, and 410 Gone on attempts to write deleted conversations. SQLite-Memory’s synchronization API already supports content replication and local embedding/FTS5 reindexing after a merge. These address important parts of the problem. They do not, on their own, constitute evidence of a complete verification contract spanning authorized original files, distributed deletion events, FTS5 materializations, and RAG citations. This article’s contribution is a limited reproducible cross-layer failure model, not invention of tombstones or local reindexing.

Deletion has stronger requirements than an ordinary edit. Suppose laptop B has document revision 12 and stays offline. Phone A commits a revocation at revision 13. When B reconnects, its old upsert must not resurrect the document simply because it arrived last. Maintain stable identity, a durable tombstone, comparable revisions or causal relationships, idempotent event processing, and a defined conflict policy. Tombstones should not be garbage-collected solely after an arbitrary seven-day timeout: long-offline replicas may never have received them. Production systems need a known-device acknowledgement policy, leases or forced rebootstrap rules before retiring deletion history.

Figure 4. A disconnected replica can continue to return stale results; tombstone delivery is the event that lets it invalidate the source. Diagram, not a remote-erasure guarantee.

There is also a race at the AI layer. A query may already have retrieved a chunk when the source is revoked, but the model prompt has not yet been assembled. Filtering only at initial retrieval leaves a gap. A more defensible approach checks the candidate source during recall and rechecks its identity, version, permission, and revocation state just before evidence enters the prompt. This cannot undo reasoning already in progress or data already disclosed, but it can prevent a known-invalid source from continuing into a later generation.

SQLite FTS5: a source table and its search index require explicit maintenance

SQLite FTS5 offers a concrete example. Its official documentation explains that an external-content FTS5 table depends on application-side maintenance of the full-text index, typically through triggers for insert, update, and delete. Inconsistent source/index maintenance may produce surprising query results. Deleting a source row is therefore not sufficient evidence that every derived index and cache was updated correctly.

When a replica receives a newer valid source revision, it should update authoritative local state and invalidate/rebuild affected search data through an idempotent and recoverable process. The exact FTS5 maintenance steps depend on table mode and SQLite version. A revoked source should also be excluded from normal retrieval by a visibility/permission predicate, even when background index cleanup is pending. Logical query invisibility and physical erasure of old index entries are separate claims.

This distinction extends below FTS. SQLite documents FTS5 secure-delete behavior and write-ahead logging, but storage cleanup depends on concrete database versions, modes, checkpoints and backups. No single SQL DELETE proves that text was physically erased from device storage, WAL histories, snapshots, exported archives, or copies already downloaded by another device. The synthetic SQLite fixture described below runs version 3.35.5 in memory; it does not exercise newer FTS5 secure-delete behavior or physical-media recovery.

What we actually tested: two synthetic fixtures, fifteen assertions

XBSTACK created two small reproducible experiments on October 29, 2026. They intentionally use synthetic documents, without access to personal files or shipping RecalAI clients.

The Node.js fixture is at experiments/local-first-ai-sync-20261029/repro.mjs. Run node --test experiments/local-first-ai-sync-20261029/repro.mjs. It models two devices with versioned source maps and simple local keyword indexes. The source records and tombstones are replicated; the index is rebuilt locally. The actual run reported 7 tests passed, 0 failed.

The Python fixture is at experiments/local-first-ai-sync-20261029/sqlite_fts5_repro.py. Run python3 experiments/local-first-ai-sync-20261029/sqlite_fts5_repro.py. It uses the standard sqlite3 module, an in-memory SQLite database, an external-content FTS5 table and source-update triggers. The environment reported SQLite 3.35.5 and 8 tests passed, 0 failed. These tests include invalidating old search terms after a source update, processing tombstones on two replicas, rejecting a stale replay, retaining unrelated records, observing stale retrieval on an offline replica, and rebuilding an index from current source-table state.

Assertion	Node.js	SQLite FTS5	Not established by these tests
Sync carries source records rather than local indexes	Pass	Pass	Real object transport and large attachments
Source change updates the local search view	Pass	Pass	OCR/chunking and neural-vector reindexing
Tombstone delivery prevents normal search retrieval	Pass	Pass	Reliable remote delivery and acknowledgement
Older operations cannot resurrect a deleted source	Pass	Pass	General multi-writer causal resolution
Deletion does not remove unrelated sources	Pass	Pass	Production tenant isolation and backup retention
Offline device remains stale until it receives the change	Observed	Observed	Immediate remote erasure, which is not possible here
Same-revision tombstone wins under the fixture policy	Pass	Pass	General CRDT conflict semantics
Index rebuild from current source data	Not covered	Pass	Large-scale performance and physical erasure

These are overlapping tests of two intentionally constrained models, not fifteen independent claims of production safety. The most useful observed limitation is that an offline replica still retrieves the old document before the deletion event reaches it. After delivery, the synthetic query stops returning that source. Both fixtures also assume that a trusted component assigned comparable monotonic revisions to each document; neither implements a production multi-writer protocol. They do not test neural embeddings, full-text file transfer, genuine network partitions, encryption/key rotation, realistic source sizes, user authentication, RecalAI code, platform-specific battery use, or backup erasure. “All tests passed” applies only to these fixtures.

Encryption, lost devices, and what a relay can still know

End-to-end encryption is not achieved merely by encrypting a blob before upload. It requires a defined trust model for device identities, key delivery, device enrollment, recovery, shared-space membership, revocation, and rotation. A cloud relay that holds only ciphertext reduces exposure of document content, but may still observe object sizes, timing, membership metadata, or traffic patterns depending on the implementation. If server-side OCR or embeddings are required, the plaintext processing boundary must be made explicit. This is a different question from whether the user supplies a model API key. For a product promising data sovereignty and user-controlled security, the practical questions are whether users can choose storage location, disable cloud sync, export their originals, revoke devices, and inspect deletion progress. On-device inference can reduce the need to send prompts to an external model provider, but enabling cross-device sync, telemetry, or cloud backups still creates data-flow and key-management obligations. Local AI is not a guarantee that no data ever leaves the device.

A server acknowledgement of deletion cannot erase plaintext that a disconnected device previously decrypted and stored. Blocking a lost device from future sync does not neutralize old local backups. Applications should therefore distinguish statuses such as “hidden on this device,” “confirmed on connected devices,” “offline devices pending,” and “backup retention still applicable.” The Microsoft agent memory safety guidance emphasizes provenance, isolation and lifecycle controls; the OWASP AI Agent Security Cheat Sheet identifies persistent memory poisoning and cross-session effects as important threats. These sources support a defense-in-depth model but do not certify any specific sync implementation.

Choosing between a relay, peer-to-peer sync and CRDTs

If the product only promises durable offline storage and local evidence-backed answers, focus first on original-file integrity, parsing, indexing and citations. A full collaborative synchronization engine may be premature. When people genuinely need the same library across phone, tablet and desktop, specify the source replication unit, permissions, conflict behavior, tombstone lifetime, device acknowledgements, encrypted storage and recovery requirements before choosing peer-to-peer transport, an encrypted cloud relay or server-readable synchronization.

Peer-to-peer does not guarantee availability when devices remain offline or cannot reach one another. A relay does not inherently require the service to see plaintext. CRDTs can solve particular classes of concurrent state updates but do not decide who is authorized to edit, how a PDF conflict should be represented, or whether deleted plaintext is physically recoverable. Technology selection should follow the failure semantics and trust requirements, not lead them.

A production-grade acceptance test would include importing a PDF on device A, receiving the original and rebuilding indexes on B, editing while both are offline, restoring connectivity and inspecting conflict handling, revoking the document and checking both retrieval and final citations, reconnecting an offline device and rejecting stale data, then testing device loss and key rotation. Capture file hashes, client versions, OS versions, model identifiers, index schema revisions, network conditions, expected observations and actual outputs. Only then can a product claim multi-device behavior with meaningful engineering evidence.

For RecalAI, this article provides a design and verification framework, not a statement that cross-device synchronization is already shipped or has passed end-to-end encryption tests. The existing BYOK privacy article covers cloud-model data boundaries, RecalAI hybrid retrieval covers retrieval and evidence selection, and Agent Memory System discusses persistent memory. The distinct question here is how authoritative knowledge sources and derived retrieval states propagate, converge, conflict, and become invalid across devices.

The durable rule is straightforward to state but difficult to implement: sources must be traceable, derived indexes rebuildable, tombstones resistant to stale replay, and citations checked against currently valid sources—while the system remains explicit about offline and physical-erasure limitations. A carefully scoped contract is less impressive than an “everything syncs instantly” claim, but far more useful to an independent developer who must support real user data over time.

Sources and evidence boundaries

• Any — Local-first, local writes, synchronization status, device indexes
• SQLite — FTS5 Extension
• SQLite — Write-Ahead Logging
• Automerge — Conflict semantics
• SQLite Sync — CRDT replication
• Microsoft — Manage memory safety in agentic systems
• OWASP — AI Agent Security Cheat Sheet
• XBSTACK reproducible fixtures: experiments/local-first-ai-sync-20261029/repro.mjs (7/7); experiments/local-first-ai-sync-20261029/sqlite_fts5_repro.py (8/8, SQLite 3.35.5 in-memory).