The notice was withdrawn. Why is the assistant still using it?

The withdrawn page still has several copies

The notice has been withdrawn from the source website. The assistant can still have its extracted chunks, a cached answer and a conversation summary that no longer names the source at all. The next reply can draw on any of them. I would follow those copies before judging the withdrawal complete, because stopping a new fetch leaves plenty of ways for the old instruction to reach another answer.

This is a freshness problem with a dependency graph. It differs from deciding who may access a document: even a public, fully authorised source can become obsolete or be withdrawn. The system needs to know which derived material depends on it and when that material stops being suitable evidence for a new answer.

Consider a fictional service notice N-14 that temporarily permits a particular remote procedure. At 14:00 the notice is withdrawn because the procedure is under review. The assistant fetched revision 6 at 13:40, indexed it at 13:45 and generated a cached answer at 13:50. A colleague returns to the conversation at 14:10 and asks whether to proceed. A fresh search of the original URL is only one part of the answer path.

Decide how long the system may take to stop using a withdrawn source. A scheduled refresh may be reasonable for some answers; an operational procedure can need a shorter bound or a current check. That choice should reflect what stale advice could cause. The indexing schedule is then something to fit around the requirement, rather than the reason an instruction remains eligible until tomorrow morning.

Map the derived artefacts before setting a timer

At 14:10 the returning colleague may receive a cached answer or conversation summary without causing a new source fetch. Follow the material those paths can use: raw copy, extracted text, chunks, embeddings, keyword entries, generated summaries and retrieved evidence packets. A source revision needs a traceable relationship to those descendants wherever they can influence the next answer.

For N-14, an index entry should retain the notice identity and revision rather than store an isolated paragraph with no ancestry. A generated summary should record which sources it used. If an answer combines N-14 with another notice, its dependency list should include both. This makes targeted invalidation possible and helps explain why an apparently unrelated cached answer needs review.

An ETag helps a client validate an HTTP representation, as MDN's explanation of revalidation describes. It does not notify every application of withdrawal or locate the embeddings and generated answers derived from an earlier copy. Those dependencies belong to the knowledge system's own records. Revalidation can check the source boundary while a separate eligibility policy governs whether its derivatives may still support an answer.

A failed fetch needs its own outcome. A server error does not tell us that N-14 was withdrawn, and a missing page means whatever the source contract says it means. Record what happened, then apply the agreed rule for uncertain evidence. Without that distinction an ingestion outage can erase a collection in one implementation and leave old instructions trusted indefinitely in another, neither of which follows from the observation actually received.

A generation boundary can block stale evidence

To stop the old advice reaching that colleague, one proposed design assigns the active corpus a generation and records withdrawn source revisions in a suppression register. New retrievals exclude those revisions before every physical index entry has been removed. Cached answers carry their source dependencies and generation, so the application can reject or refresh an answer whose evidence is no longer eligible.

For N-14, withdrawal at 14:00 could update the suppression register immediately after the authoritative event is received. Index cleanup might finish at 14:03. Between those times, a query can still encounter an old physical entry, but the application must filter it before treating it as usable evidence. The logical boundary and the cleanup process are related, not identical.

This design has a race to resolve. A request may retrieve N-14 at 13:59 and finish generation at 14:01. Checking only at retrieval allows it to publish a newly stale answer. For consequential guidance, recheck the evidence’s eligibility before presenting the result or executing an action based on it. Decide how the application handles a change during generation: restart, return a bounded explanation or refer the question.

Also check the worker that started earlier. It may have fetched revision 6 before withdrawal and finish indexing afterwards. Consult the current source eligibility or generation before accepting that write, so a late completion cannot restore the notice. Retain the withdrawal marker for the documented replay and retention period. Physically removing every trace of the event can leave the application with less information to reject the old work arriving later.

The final eligibility check needs a defined consistency guarantee. If independent services see a suppression update at different times, the policy must state and monitor the intended propagation bound. Consequential instructions may require stronger coordination. An event announcing withdrawal starts that work, but its existence alone cannot establish when every service involved in producing or presenting an answer has stopped accepting the source.

History may remain, but it should stop posing as current advice

For the colleague returning at 14:10, the previous answer is history rather than current authority. Deleting it may be inappropriate or impossible. The application can instead mark its source as withdrawn and assemble the next request with that status visible, so the earlier advice cannot silently become the instruction for proceeding now.

If an old summary lost its source dependencies, the application cannot later identify all of N-14’s descendants precisely. It may have to invalidate a broader set or require current evidence before another operational answer. Say which conservative step was taken. The wider disruption has a cause—the earlier loss of provenance—and improving the next summaries’ dependency records is more useful than claiming the current system traced copies it can no longer recognise.

Distinguish correction from withdrawal. A corrected notice may replace one instruction with another; a withdrawn notice may leave no approved procedure. Generating a new affirmative answer from nearby documentation can be wrong if the relevant authority has deliberately paused the work. “The notice was withdrawn; the current procedure needs confirmation” is sometimes the most useful answer available.

The same caution applies to downloaded exports and messages already sent. An index purge cannot recall a PDF in somebody’s inbox. If the product’s purpose requires notifying recipients about a material correction, that is an additional distribution and acknowledgement process. Keep its scope explicit rather than treating removal from search as completion of every obligation.

Measure the withdrawal path, not just the ingest path

A freshness review should record times at each relevant stage: authoritative withdrawal, event received, suppression effective, cached answers blocked and index cleanup complete. The critical measurement is when a new user-visible answer can no longer rely on the withdrawn source. Counting how quickly an embedding was deleted may measure a different and less important boundary.

In the synthetic N-14 sequence, withdrawal at 14:00, receipt at 14:00:10 and effective suppression at 14:00:20 give a twenty-second source-to-suppression interval. Cleanup ends at 14:03. The twenty-second claim is valid only if old index entries, cached results and in-flight answers are actually blocked at that boundary. Measuring an internal update without checking those output paths would establish a narrower milestone.

Exercise the final answer boundary

Exercise a query already running at withdrawal, a cached answer, a returning conversation and a failed source check. Observe which evidence reaches the final response. Keep the cases distinct: a newly fetched answer can be fresh while the conversation continuation remains stale. Checking the final response establishes whether the withdrawal policy holds for that particular route.

Not every knowledge base needs the same machinery. A collection of historical essays can tolerate a different refresh schedule from operational procedures. The important choice is to state what may become stale, how long it may remain eligible and what happens when current evidence cannot be established. A universal short expiry can waste resources without solving the dependency problem.

At 14:10 the colleague needs to know whether the procedure may proceed. If its notice is withdrawn and no replacement is approved, the answer needs to leave that decision open and identify where confirmation can come from. A cleaned index is helpful only if the cached answer and returning conversation respect the same withdrawal. Test the twenty-second claim on that next reply, where old advice could otherwise become a new instruction.