An analyst asked our system a routine question and got a clean answer back. It cited a policy clause by number, quoted it almost word for word, and read like every good answer the tool had given that week. The only problem was that the clause had been revised in the spring. The version the analyst was reading, and about to act on, had been retired for months. The model had not made anything up. It had retrieved a real document, grounded its answer in real text, and told the truth about a source that was no longer true.
The part that should worry you is that nothing failed. There was no error, no timeout, no low-confidence warning, no red flag anywhere in the trace. Retrieval found a document, the model built an answer on it, and the answer came out with the same steady tone as all the correct ones. Staleness is the one failure mode in a grounded system that has no symptom. It looks exactly like success, right up until someone who knows the current policy reads the output and asks where on earth that came from.
Retrieval always hands back something
Grounding gets sold as the cure for hallucination. Stop letting the model answer from memory, tie every answer to a document you actually hold, and the making-things-up problem goes away. That is true as far as it goes, and it does not go as far as people think. Grounding does not remove the trust problem. It moves it. You stop having to trust the model's memory and start having to trust the corpus, and the corpus has failure modes of its own that are quieter than anything the model does.
The core one is simple: a retriever always returns something. Ask it a question and it hands back the closest match it can find, ranked by similarity, whether or not that match is current. It has no sense that the document it just surfaced was superseded in March. It only knows the text is a close fit for the question. So the retired policy, the delisted supplier, the withdrawn guideline all sit in the index looking exactly as relevant as the versions that replaced them, and the model, doing its job faithfully, answers from whichever one the retriever ranked first.
Freshness is a property of the corpus, not the model
Most enterprise AI arguments are about the model. Which one, how big, how long a context window, how clever the prompt. Freshness does not live in any of those places. It lives in the pipeline that put a document into the index and, far more often than anyone admits, never took it back out. You can pair the best model on the market with a corpus nobody has weeded since last year and get fluent, well-reasoned, professionally worded answers built on facts that stopped being facts two quarters ago. The quality of the sentence tells you nothing about the age of the source underneath it.
We wrote earlier that the answer was never the hard part, that provenance, the record of where a fact came from, is what separates a trustworthy answer from a confident one. Freshness is the question that comes right after provenance. Knowing which document an answer came from is necessary. It is not sufficient. The next thing you have to know is whether that document is still the version the enterprise actually stands behind, or a copy the world moved past while it sat quietly in your index, still perfectly retrievable.
The document you retired is still answering
Here is where it turns from a quality nuisance into a governance problem. Someone changes the source of truth. A policy gets revised, a supplier gets suspended, a clinical guideline gets withdrawn. They do the right thing at the system of record: they update the master, they mark the old version dead, they move on believing the change has taken effect everywhere. What they almost never do, because it is invisible from where they sit, is update the copy that was embedded into the vector index weeks ago. That copy does not know it was retired. It keeps getting retrieved, and it keeps answering questions as though the revision never happened.
Deletion at the source does not propagate to the index on its own. Someone has to build the path that carries a retraction from the system of record all the way through to the embeddings, and that path is exactly the piece most retrieval stacks skip because it is unglamorous and nobody notices its absence until it bites. On NeuraMed, a guideline that was pulled by the issuing body can keep surfacing because the old document is still sitting in the store, still a strong match for the question. On MatryxAI, a supplier suspended for cause can keep coming back as an approved option because the record that flagged it never reached the index the sourcing workflow reads from. The source of truth said no. The retriever never got the message.
Lineage is the record of where a fact has been
The control that makes any of this manageable is lineage. For every fact the system can retrieve, you should be able to name four things without a forensic investigation: which document it came from, which version of that document, when it was ingested, and when it was last confirmed to still be current. That is not bureaucracy. It is the only way to answer the question that surfaces the moment a bad answer does: was the source wrong, or did the model misread a source that was fine?
Without lineage those two failures are indistinguishable, and they have opposite fixes. A model that misreads a good document needs a prompt or a reasoning fix. A model that faithfully reads a retired document needs a corpus fix, and no amount of prompt tuning will touch it. Lineage is what lets you tell them apart in minutes instead of days, and it is why the trail belongs in the audit log next to the rest of the decision, not in a data-engineering system nobody in the room can see. Which source answered, and how old it was, is part of the story of how the decision got made.
Freshness has to be a number, not a mood
"Our data is fresh" is a feeling, not a control. The version that holds up is a staleness budget set per class of source, because not all data ages at the same rate. A supplier suspension has to reach the index in hours, or the workflow is making decisions on a status that is flat wrong. Revised policy language might tolerate a few days. A reference table that changes twice a year can sit for weeks without anyone being the worse for it. Each class of source gets an allowed age, and the platform tracks the real age of everything it serves against that budget.
Once age is a number the system knows, you can act on it instead of hoping. A source inside its budget answers normally. A source past its budget gets flagged, down-weighted, or held back entirely, so a document that aged out does not get to answer with the same unbothered confidence as one ingested this morning. That is the difference between a corpus you maintain and a corpus you accumulate. One knows how old it is and does something about it. The other just keeps growing, quietly carrying every stale answer it will ever give.
This belongs under the stack, not in every app
Every solution that retrieves anything faces this identical problem, which is the tell that it should not be solved inside any one of them. If each application builds its own freshness check, its own version tracking, its own way of carrying a retraction from the source through to the index, you get the same sprawl we have written about before, the dangerous machinery rebuilt slightly differently in every corner of the portfolio, each copy with its own gaps. Lineage, freshness budgets, and retraction propagation are platform concerns. They belong in the substrate.
In our architecture that substrate is Neura-Cortex, the shared layer under the solutions, sitting alongside the guardrails, the identity, the routing, the evals, and the audit log. Freshness gets provided once and inherited by everything built on top, so a team shipping on Lumen or Clairant or Throughline does not reinvent staleness handling under deadline and quietly leave out the retraction path. They get the corpus discipline the platform already enforces, and every answer carries the lineage of the source behind it because the layer underneath put it there.
Stale data is a governance failure, not a data chore
Freshness usually gets filed under data engineering, where it competes with feature work for attention and loses, quarter after quarter, because nothing is visibly broken. That filing is the mistake. A system that confidently answers from a policy the company retired is not having a data-hygiene hiccup. It is committing a governance failure in the same family as an agent acting outside its authority, and it should be treated with the same seriousness. When it surfaces in an audit, the reviewer will not be soothed to hear the ingestion pipeline was healthy. They will want to know why a decision cited a rule that no longer existed, and "the document was still in the index" is not an answer anyone wants to give.
It connects to something we said about the half-life of a working model: software fails loudly, and AI erodes quietly. The model is not the only thing that erodes. The ground it stands on erodes too. A retrieval corpus that was accurate at launch drifts out of date one unretracted document at a time, and a freshness sign-off that happened at go-live is a photograph of a corpus that has been changing ever since. The control is not a clean-up you run once. It is a discipline that keeps running, because the day you stop maintaining freshness is the day your grounded system starts confidently answering from the past.
A grounded answer is only as current as the oldest document your retriever is still willing to return. If nothing is checking that age, "grounded" and "confidently wrong" look identical on the way out.
What a source has to prove before it can answer
Before a document earns the right to ground an answer in one of our workflows, there are a handful of questions it has to survive. When was it last confirmed current, and by whom? If the source of truth changed yesterday, how many hours until the index reflects it, and who measured that number rather than assuming it? When a document is retired at the source, what deletes its copy here, and do we actually test that the deletion happened rather than trusting that it did? For any answer the system produces, can we name the source, the version, and its age on demand? And what is the oldest a document in this class is allowed to be before we stop letting it answer at all?
A corpus that cannot answer those is not grounded. It is a pile of documents that happens to include some current ones, and it will hand back the stale copies with exactly the same confidence as the fresh ones, because to the retriever they are all just text. Most retrieval stacks running today would fail at least two of those questions, and the failures are invisible precisely because the answers still read well. Good grammar on a dead source is the most convincing wrong answer an enterprise system can give.
Pick one high-stakes answer your AI produced last week. Trace it back to its source: which document, which version, ingested when, confirmed current by whom. If you can do that in a few minutes, you have real lineage. If you cannot, or if the trail ends at a document nobody has looked at since spring, you do not yet have a grounded system. You have a confident one, and the difference only shows up on the day it matters most.
The best-run corpus I have looked at this year was not the largest or the most cleverly indexed. It was the one that knew the age of everything it served and refused to answer from anything past its budget, the one where a retraction at the source reached the index the same day and you could prove it had. It was not exciting to demo. Nobody claps for a system that declines to answer from a document it no longer trusts. But every answer it gave could be traced to a source someone still stood behind, and that, far more than the size of the model or the cleverness of the prompt, is what separates an AI you can put in front of a regulator from one you can only put in front of a friendly crowd.
MTekLabs designs, deploys, and governs production-grade agentic AI platforms for government and commercial enterprises. Our solutions are built human-in-the-decision-loop where it matters and auditable by design. Explore them at mteklabs.com.
Do you know how old the data behind your answers is?
We would be glad to walk through where your retrieval corpus could be answering from documents your enterprise has already retired, and what it takes to give every answer a traceable source, a known age, and a retraction path that actually reaches the index.