How to Synchronize Enterprise Knowledge Sources for Private RAG

Most private RAG projects treat ingestion as the hard part: connecting to the repositories, extracting text, chunking sensibly, generating embeddings, and getting access labels attached correctly. That work is genuinely demanding, and designing the ingestion pipeline well determines much of what follows.

But ingestion happens once. Synchronization happens forever — and it is where working systems quietly degrade. Six months after launch, the index contains policies that were superseded, procedures for a system that was decommissioned, chunks from documents that were deleted, and access labels that no longer match the permissions in the source repository. The system still answers confidently. It is simply answering from a past version of the organisation.

This guide covers how to keep a private RAG index aligned with the enterprise sources behind it: detecting change, propagating deletion, tracking permission drift, and handling the events that force a full rebuild.

Four things decay, and they decay differently

“Stale index” describes four distinct failures, each needing its own mechanism:

• Content drift. A document was edited; the index still holds the old text. Impact ranges from trivial to serious depending on the corpus.
• Deletion drift. A document was removed or superseded; its chunks remain retrievable. This is the most dangerous case, because the system will cite a retired policy as authoritative with no signal that anything is wrong.
• Permission drift. Access to a document changed in the source system; the index still carries the old labels. This is a security problem, not a freshness problem, and it deserves a tighter cadence than content sync.
• Representation drift. The embedding model, its version, or the chunking strategy changed. Nothing in the source moved, but the index no longer represents the corpus consistently.

Teams that conflate these end up with a single nightly job that handles content adequately, deletion unreliably, permissions not at all, and re-embedding as an emergency.

Change detection: source signals first, hashing as the arbiter

Every incremental sync needs a deterministic answer to “did this change?” There are two families of answer, and mature pipelines use both.

Source-side signals are cheapest: change feeds and delta queries from document management systems, webhooks where the platform offers them, and change-data-capture streams for the databases feeding database-connected RAG pipelines. These tell you what to look at without scanning the whole corpus.

Content hashing is the arbiter. Last-modified timestamps are notoriously unreliable — bulk migrations touch every timestamp without changing a word, permission edits can bump the modification date, and some systems fail to update it for edits made through certain paths. Hashing the extracted text together with the metadata that affects retrieval gives a definitive comparison. The cost is reading and extracting the document, which is why the source signal narrows the candidate set first.

Both approaches depend on identity. Assign a stable document ID derived from the source system’s own identifier — not a file path, which changes when someone moves a folder — and a stable chunk ID derived from the document ID plus chunk position. Without these, updating a document means either duplicating its content in the index or wiping and rebuilding more than you intended.

Deletion is the failure that matters most

An index that lags a day behind on edits is usually tolerable. An index that keeps serving a policy the compliance team retired eight months ago is not, and users have no way to detect it — the answer arrives with a citation to a document that genuinely said that, once.

Three mechanisms together make deletion reliable. First, event-driven removal: when the source signals a delete, remove every chunk carrying that document ID. Second, supersession handling: many enterprise documents are not deleted but replaced, and the pipeline needs to know that policy-v4 retires policy-v3 rather than sitting alongside it — usually a metadata convention that has to be agreed with the document owners, not inferred. Third, periodic reconciliation: a scheduled sweep that lists the source inventory, compares it against the document IDs present in the index, and removes orphans. Event streams drop messages; the sweep is what makes deletion eventually consistent rather than best-effort.

One caveat worth raising early with legal and records teams: removing a document from the retrieval index is not the same as deleting it from the record system, and retention or legal-hold obligations attach to the latter. Keeping the two concerns separate — index membership versus record retention — avoids an awkward conversation later.

Permission drift is a security control, not a freshness metric

Access labels attached at ingestion are a snapshot. People change teams, projects close, contractors leave, folders get re-permissioned. If the index does not track those changes, retrieval starts returning content to people who are no longer entitled to it — and because retrieval is invisible to the user, nobody notices until an audit or an incident.

Three practices reduce the exposure. Synchronize entitlements more frequently than content, since they change more often and matter more. Prefer group- and role-based labels over enumerating individual users, so a single membership change in the directory propagates without touching the index at all. And where the workflow’s sensitivity justifies it, re-check entitlements against the source of truth at query time, using indexed labels as a fast pre-filter rather than the final authority.

When entitlement data for a source is stale beyond its threshold, the safe default is to exclude that source from retrieval rather than serve it on old labels. This is the same principle behind metadata filters in private RAG and department-level data isolation: the access model belongs to the data, and retrieval is bounded by it.

Re-embedding is a migration, not a sync

Changing the embedding model — or upgrading its version, or materially changing chunk size and overlap — invalidates the entire index. Vectors from two models are not comparable, so a half-migrated index produces retrieval that is quietly incoherent.

Handle it as a planned migration: build the new index alongside the current one, evaluate both against a fixed test set of real questions with known-correct passages, compare results, then cut over and retire the old index. Version-pinning the embedding and reranker models in production, as discussed in embedding models and rerankers for on-premises RAG, is what prevents this from happening by accident when a serving stack updates underneath you.

For large corpora, budget the re-embedding compute honestly. It is a one-off job, but it is a substantial one, and it competes with inference for the same GPUs.

Set freshness targets per source, and measure the lag

Not every source deserves the same cadence. A policy library that changes quarterly does not need near-real-time sync; an operational runbook set that changes daily does; a pricing table that changes hourly may not belong in a vector index at all and is better served by a tool call to the system of record at query time.

Assign each source a freshness target, then measure against it. The metric that matters is sync lag — the age of the oldest un-propagated change per source — not “the job completed successfully”. A pipeline can complete cleanly every night while silently failing to process one repository. Worth instrumenting alongside it: orphaned chunk counts from reconciliation sweeps, extraction failure rates by source and file type, entitlement sync age, and the count of documents skipped because they could not be parsed. Surfacing document dates in answers helps too — a user who can see that the cited procedure was last updated two years ago can judge for themselves whether to trust it.

How VDF AI handles synchronization

VDF AI runs the full retrieval pipeline inside the customer’s environment, and treats synchronization as part of the platform rather than a script someone maintains on the side. Connectors track source-side changes and reconcile against the index, deletions and supersessions propagate to the chunk level, entitlements are refreshed from the directory and enforced at retrieval, and re-embedding runs as a controlled migration with the old index available until the new one has been evaluated.

Because the whole pipeline — extraction, embedding, indexing, retrieval — runs locally, sync activity never sends a document or a fragment of one outside the boundary. The result is that a private enterprise knowledge assistant still reflects the organisation a year after launch, which is the only condition under which people keep trusting it.