Direct answer
Treat freshness as a source-to-index lifecycle, not a scheduled re-embedding job. Every source needs an owner, change-detection method, version, ingestion status, retry path, retention rule, and deletion behavior. A RAG system is current only when it can prove which version was searchable, when it changed, and whether every derived artifact changed with it.
Retrieval cannot repair stale knowledge
Teams spend heavily on chunking, embeddings, reranking, and prompts while assuming the corpus is correct. Retrieval may find the most relevant chunk in the index and still return an outdated policy, superseded regulation, or deleted customer file.
That is not a model failure. It is a publishing failure inside the knowledge system.
The first design question should be: what event makes this source stale? For a policy library, it may be a new approved version. For a public website, it may be a changed content hash. For uploaded customer documents, it may be replacement, permission change, or deletion. Each source type needs a rule that reflects how truth changes.
Give every source a lifecycle
A production ingestion record should carry a stable source ID, tenant, origin, checksum, source version, observed timestamp, processing status, access policy, and retention state. Derived chunks and embeddings must point back to that record.
That lineage makes four operations possible:
- update only what changed;
- stop an older version from competing with the new one;
- delete all derived artifacts when the source is removed;
- show which source version supported an answer.
Without lineage, a vector index becomes a pile of text that cannot be governed safely.
Change detection comes before extraction
Reprocessing every document on every run is expensive and creates more opportunities for partial failure. Detect change as early as possible using content hashes, ETags, modification metadata, feed events, or source-system webhooks.
Zenveus used this pattern in CARA, a regulatory knowledge platform spanning 35,643 rules from 1,994 sources. Web content was fingerprinted, stored PDFs were checked for changes, and unchanged material stopped before paid scraping, extraction, and embedding. When content changed, queues separated retrieval from embedding, while content hashes made processing idempotent.
The result was not simply a large index. It was a monitored knowledge pipeline designed for rules that keep changing.
Partial success needs a visible state
Ingestion is rarely one step. A file may upload successfully but fail OCR. Extraction may finish while embedding times out. The new version may be indexed while the old version remains active.
Represent those states explicitly. Do not mark a source “ready” until every required stage succeeds and the index swap is complete. Keep the prior good version searchable when the new one fails, then surface the failure to an operator with enough detail to retry safely.
Freshness dashboards should show source age, last successful ingestion, failed stages, queue depth, orphaned chunks, pending deletions, and documents with no valid current version.
Deletion is part of freshness
When a user deletes a document or loses access, the system must remove or quarantine the raw file, parsed text, chunks, embeddings, summaries, caches, and search references according to policy. Filtering only the application record while derived content remains retrievable is not deletion.
The same rule applies to permissions. If access changes, retrieval must enforce the new authorization context immediately—even if the content itself did not change.
Test freshness with known changes
Maintain a small freshness suite. Update a source, remove a paragraph, revoke access, replace a file, and delete it. Verify that search returns the correct version at every step and that citations resolve to the source a user can actually open.
The acceptance test is simple: can the team explain exactly why an answer used this version and not the one before it?
If not, the RAG system can retrieve. It cannot yet manage knowledge.
Related Zenveus services: Agentic AI Development and SaaS Development