A stale-context override is the system telling you that the data it would act on is older than the freshness budget you set, and asking what to do. The decision is yours. The three paths look superficially similar and differ significantly in their downstream consequences.
What stale context looks like
The system has a freshness window of 15 minutes on vendor price data. The last refresh of the vendor's price sheet was 22 minutes ago. The system is being asked to draft a PO using that price data. The freshness budget is exceeded by 7 minutes. The system pauses and surfaces the override prompt to the operator: "the price data is 22 minutes old, exceeding your 15-minute budget. How do you want to proceed?"
The system is doing its job. The freshness budget exists precisely to catch the case where the data has aged out of relevance. The operator now has three paths.
The three paths
Path 1: refresh the source and retry
The right answer in roughly 85% of cases. Trigger a fresh fetch of the source, wait the 30 seconds it takes, and let the system act on current data. The cost is 30 seconds. The benefit is that the downstream write is against current data and the audit trail shows clean freshness.
The reason this is the default: the freshness budget exists for a reason. Acting on stale data is what the budget is supposed to prevent. The 30-second cost of a refresh is almost always smaller than the cost of a bad write that has to be corrected later.
Path 2: approve as stale, with reason
The right answer when you have specific knowledge that the source is unlikely to have moved. Example: you know the vendor publishes price updates weekly on Mondays. It is Wednesday. The last refresh was 22 minutes ago because of a polling glitch, not because the price has changed. You can approve the stale data, with a recorded reason that explains why you believe the staleness is harmless.
The reason is load-bearing. Without it, the override is invisible to the next operator and to the auditor. With it, the override is defensible. The pattern that fails is the operator who routinely approves as stale without recording a reason. After three months, half the system's writes are against stale data, the freshness budget is decorative, and the cleanup is significant.
Path 3: defer the decision
The right answer when you cannot quickly tell whether the source has moved and the downstream write is not urgent. Defer the proposal to the next refresh cycle. The system will retry against fresh data. If the proposal still makes sense at that point, you can approve cleanly. If the proposal has been superseded by new information, you have avoided a write that would have needed correction.
Defer is undervalued. Operators tend to think they need to make a decision now because the proposal is in front of them. The system has already absorbed the latency cost of the stale data. Adding 15 more minutes of latency to get fresh data is rarely the difference between a good outcome and a bad one.
The hidden fourth path
There is a fourth path that operators sometimes take and that is almost always wrong. Approve as stale without recording the reason because the queue is long and the reason field feels like friction. The fourth path is a form of silent acceptance and is the failure mode the freshness budget exists to prevent.
The fourth path produces an audit trail that looks fine (the override is recorded) and is operationally useless (the reason is missing, so nobody can tell whether the override was thoughtful or reflexive). When the cleanup arrives months later, the operator who is asked to explain their decisions cannot.
How to set the freshness budget so the overrides are rare
A freshness budget that triggers an override on most proposals is too tight. The operator burns out on overrides and the system stops being useful. A budget that almost never triggers an override is too loose and is decorative. The right budget triggers overrides on roughly 3-8% of proposals.
Setting the budget requires knowing two things. The natural refresh rate of the source (how often does it actually move?) and the operational tolerance for staleness on this workflow (how stale can the data be before the write is structurally wrong?). The budget sits between those two numbers, leaning toward the looser of the two for sustainability.
What the post-mortem looks like
When a bad write happens and the audit log shows a stale-context override, the post-mortem walks the override reason. If the reason is specific and defensible ("Wednesday, vendor publishes Mondays, polling glitch"), the override was correct and the problem is elsewhere. If the reason is missing or generic ("routine"), the override is the proximate cause and the operator has to explain their decision-making rhythm. Skipping the reason is the move that turns a routine workflow incident into a personnel question.