A RAG application may provide useful answers at handover and later offer outdated information. A source changes, an appendix is withdrawn or a content owner leaves the team. The technical environment can remain available while answers no longer reflect the current process. Source freshness therefore belongs in design and handover rather than only in an operating agreement added afterwards.
This guide makes day-to-day responsibility concrete. Situations and timing are illustrative design choices, not promised service levels or descriptions of an existing customer environment. Choose the required speed and checks according to the consequences of outdated information or access that is no longer appropriate.
Define the freshness required by the task
Not every source needs the same update timing. General introductory material may change less urgently than a current product warning. For each source area, describe how quickly a change must become useful and what delay would mean. A broad promise of regular refresh says little about the questions staff rely on when completing work and applying instructions.
Ask the content owner when the document becomes effective. A revision may be published ahead of its start date. Conversely, a source may be withdrawn immediately before replacement guidance is ready. Make these moments recognisable. The application needs a sensible response during a period when a topic requires clarification or a human route rather than an apparently complete answer based on withdrawn material.
Record the state of each source
Keep a stable reference, expected version and last successfully processed version. A timestamp showing that a connector ran does not prove a particular document became correctly available. Distinguish discovered, processed, reviewed and actively used material where those steps can succeed or fail independently within the actual design. This makes a status meaningful for investigation rather than merely reassuring.
An illustrative service company replaces a manual and sees a green import result. One table has nevertheless become unreadable and an old passage remains available through retrieval. Without source-level records the situation is difficult to identify. An operating view need not be elaborate, but it should help the owner connect a particular document and a known question to the state of its processing.
Investigate how changes are detected
A connector may identify changes through timestamps, version data or another source capability. The mechanism needs to match how employees actually maintain files. Consider a moved document, reuploaded appendix or file whose name stays unchanged while its content changes. Record supported cases and limitations rather than assuming every change to a source location appears automatically as a correct content update.
Run a small trial using those exact operations. Afterwards inspect not just whether processing started, but which text retrieval returns and which version the citation opens. A technically successful synchronisation may still produce the wrong substantive result. Evidence of freshness should therefore connect the source change to visible behaviour on the questions affected by the revision.
Record who can act when something changes and what evidence a new maintainer needs: Handing over existing software operations: let a second person perform the work.
Make partial processing a recognisable outcome
An update may succeed only in part. Some sources are current, others remain old and a third group is missing after a temporary failure. Discuss whether the application may use that mixed state and what users need to know about it. Where instructions depend on one another, partial renewal may be less useful than a deliberate temporary restriction on the affected topic.
Define recovery that does not depend on an unexplained full reimport. A maintainer should be able to identify the missing source and the check required before it becomes active again. Agree who may continue, temporarily return to an earlier reviewed state or disable a source area until its update is correctly processed. These are operational decisions with substantive consequences, not merely connector settings.
Treat withdrawal differently from ordinary refresh
A withdrawn document may need removal more quickly than the normal refresh cycle. It could contain an incorrect instruction or have a newly restricted audience. Investigate derived passages, search results, answer caches and previously shared citations. Deleting the original file alone does not establish that its contents are no longer being offered as current support elsewhere in the application.
Prepare a withdrawal test. Ask a question using the source, withdraw it and try new questions and previously visible links again. Record what changes immediately and which parts require additional processing. Do not promise immediate removal everywhere before the actual source chain and retention choices have been investigated and checked. The necessary boundary should follow from the purpose and consequences of that information.
Separate technical and editorial ownership
A technical maintainer may see an import failure. A content owner determines whether a revised procedure is correct and when it should apply. Assign both responsibilities and a backup. Otherwise technical staff may wait for approval while the department assumes a successful upload means the new instruction is already being used correctly by everyone accessing the knowledge application.
Keep the handoff practical. A change request may include the source reference, reason, intended effective date and accountable person. Add the questions that need reassessment. This gives technical work a substantive check without turning every small correction into an unnecessarily large project procedure. The degree of control should follow the effect of the change on the work the application supports.
Reassess questions affected by the update
A different product term, revised table or new exception can affect both retrieval and answers. Select relevant cases from the existing evaluation collection. Check the correct source is found, the new condition is retained and an old response is not still supplied through reuse. Technical availability alone will not reveal these changes in the meaning of the information available to users.
Preserve cases whose expected outcome deliberately changes as well. A reviewer should be able to explain why the new answer ought to differ. That supports user questions and prevents an improvement being reversed later as an unexplained regression. Connect the evaluation result to the source change so the reason remains available to the next person maintaining the collection.
Give users a practical reporting route
A colleague may first notice that a citation opens an old version or a procedure is missing. Route that report to someone able to investigate the topic. Ask for an identifiable source or answer reference and a short explanation rather than automatically requesting all confidential details from the conversation. This keeps diagnosis focused on the relevant failure instead of accumulating unnecessary material.
Explain what happens to the report. Sometimes content changes, sometimes the question is outside scope and sometimes further investigation is needed. Closing a report without a substantive explanation weakens confidence in the route. Also clarify when users should temporarily consult the original source or a responsible specialist directly because a particular topic is not yet being supported dependably by the application.
Rehearse maintenance before independent handover
Have the future owner perform a normal change, withdrawal and failed-processing scenario. Can they establish what is active, understand an alert and repeat the relevant questions? A manual explaining button locations alone does not prove that the daily process is workable for the people taking responsibility or that the information needed for recovery is actually available to them.
Keep the exercise with known limitations and agreed support channels. Reassess when new source types or audiences are added. The aim is not an unlimited guarantee of freshness, but a manageable chain in which changes become visible, responsibilities remain clear and users know how to proceed when information is not yet correctly available through the knowledge application.
Turn the explanation into a project decision
Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.
Open the preparation tool ↗Questions about this topic
How often should a RAG index be updated?
That depends on the source and the consequences of outdated information. Agree an appropriate freshness boundary for each area and investigate whether the proposed processing can meet it. A fixed daily interval is neither sufficient nor necessary for every application.
Can we remove an old source only from its original folder?
First investigate derived passages, indexes, caches and links. Removing the original does not prove the application no longer uses its contents. Test the relevant chain and define any controlled historical retention separately.
What belongs in a useful maintenance handover?
Recognisable source states, ownership, change and withdrawal routes, alerts, relevant evaluation cases and a rehearsed recovery process. The owner should understand what they can do independently and when technical or substantive assistance is required.
Continue with a related question
Prepare company documents for RAG: build a managed source collection
Make documents useful for a RAG trial through ownership, validity, structure, removal rules and representative checks.
RAG & business knowledgeRAG access control: who may retrieve which company information?
Define users, organisations, source permissions, caches and revocation before making internal knowledge available through AI.
Existing software & auditsHanding over existing software operations: let a second person perform the work
Make an operational handover testable through account ownership, versions, release, alerts, recovery, escalation and rehearsed replacement.
Sources and technical background
- OWASP: Authorization Cheat Sheet ↗
Authorisation principles; the worked evaluation cases are illustrative.
- NIST: AI Risk Management Framework ↗
Framework for organising AI risk management, not product certification.