Frequency:Common
An agent retrieves and applies information that was once the accepted best practice in a domain but has since been superseded by an evolved standard, even though the underlying fact is still technically true. The agent's knowledge source (a fine-tuned model, a static knowledge base, or a cached document set) captured the practice at a point in time and was never re-indexed against the field's current consensus, so the agent confidently recommends an approach that a current practitioner would flag as outdated. The advice isn't factually wrong in isolation — it's wrong relative to what the domain now considers correct.
Frequency:Occasional
An agent produces output or takes an action that violates a hard, non-negotiable constraint of the domain it's operating in — a regulatory requirement, a safety interlock, a licensing restriction — because the constraint was never surfaced by its retrieval layer. Unlike a best-practice miss, this isn't a matter of degree: the agent crosses a bright line (e.g. recommending a drug dosage that exceeds a labeled maximum, or drafting a contract clause that's unenforceable in a given jurisdiction) because its knowledge base treated the constraint as optional context rather than a gating rule.
Frequency:Common
An agent correctly establishes domain-specific context early in a session — the specialty, jurisdiction, or technical stack it should reason within — but loses track of it as the conversation grows, silently reverting to generic, domain-agnostic behavior. The regression isn't triggered by the user changing topics; it happens because the domain-framing information falls out of the effective context window or gets diluted by intervening turns, and nothing in the agent's architecture re-asserts it.
Frequency:Common
An agent correctly retrieves and applies a general domain rule, but fails to recognize that the specific case at hand falls under a documented exception that overrides or modifies the general rule. The exception exists in the knowledge base — often in a separate section, footnote, or appendix — but the agent's retrieval or reasoning never connects the specific case to it, so the general rule is applied as if it were universal.
Frequency:Occasional
An agent operating in a specialized domain fails to flag a risk factor that any competent domain practitioner would immediately recognize as significant, not because the underlying fact is missing from its knowledge base, but because that fact was never tagged or weighted as risk-relevant. The agent retrieves and states the fact correctly when directly asked, yet doesn't proactively surface it as a concern in a context where a domain expert would treat it as a red flag requiring attention.
Frequency:Common
An agent retrieves a correctly-stated domain rule but misapplies it because it misreads the precise conditions under which the rule holds — extending it to cases just outside its actual scope, or narrowing it to exclude cases it actually covers. The rule text itself is never altered or hallucinated; the failure is in the agent's interpretation of qualifying language like "only if," "except when," or "applies to X but not Y" that defines the rule's true boundary.
Frequency:Common
An agent interprets a domain-specific term using its common, general-language meaning instead of the narrower or entirely different meaning the term carries within the specialized domain, producing a response that's coherent but answers the wrong question. This happens most with terms that are ordinary English words repurposed with precise technical meaning (e.g. "significant" in statistics, "material" in accounting, "positive" in a lab result), where the domain meaning can even be the near-opposite of the everyday connotation.
Frequency:Very Common
A retrieval system pulls a fact that is accurate on its own terms, but the qualifying context that makes it correctly applicable — the condition, population, or scope it was originally stated under — is dropped somewhere between the source document and the agent's final answer. The fact survives; the sentence or clause that scoped it does not, usually because chunking, summarization, or context-window truncation separated the fact from its qualifier.
Frequency:Very Common
An agent takes a fact that is true only under narrow, specific conditions — a particular study population, a specific product configuration, a specific regulatory jurisdiction — and presents it as a general truth applicable broadly. The source fact isn't misquoted; the error is in stripping away the scope that made it narrowly true and applying it as if it held universally.
Frequency:Occasional
An agent retrieves a fact correctly in terms of subject matter but reverses its direction or polarity — reporting "increases" when the source says "decreases," "improves" when the source says "worsens," or swapping which of two entities has the higher value. The topic and the entities involved are right; the relationship between them is flipped, which is often more damaging than an unrelated error because it's confidently stated and directionally opposite to the truth.
Frequency:Occasional
An agent drops, adds, or misplaces a negation while processing retrieved text, asserting the opposite of what the source actually states. Unlike a full directional inversion, this failure is specifically about negation words and constructions ("not," "no longer," "except," "unless," double negatives) being mishandled during retrieval, summarization, or paraphrase, producing a claim that reads fluently but contradicts the source on the single most important word in the sentence.
Frequency:Very Common
An agent presents a fact that is technically accurate as stated but omits a critical qualifier that would materially change how a user should act on it — not because the qualifier is missing from the source, but because it was dropped somewhere in retrieval or generation and the resulting statement, while not false, is misleadingly incomplete. This differs from a fabrication: every word the agent says checks out against the source, but the selective omission changes the practical meaning.
Frequency:Common
An agent retrieves a fact that was expressed by its source with explicit probabilistic or statistical framing — a likelihood, a confidence interval, a rate observed in a sample — and restates it as a flat, deterministic certainty, dropping the uncertainty that was integral to the original claim's meaning. The number or direction carried over is often correct; what's lost is the epistemic status of the claim, turning "this happens in about 30% of cases" into "this happens" or "this is what will happen."
Frequency:Occasional
An agent retrieves facts about two distinct entities — companies, people, products, or regulations — that share a similar name, and conflates attributes from one with the other in its response. The resulting statement is internally coherent and often partially correct, but attributes a fact that belongs to Entity A to Entity B, because retrieval matched on name similarity rather than correctly disambiguating which entity the query actually concerns.
Frequency:Common
An agent retrieves a fact that was true during a specific window of time and applies it outside that window, because the fact's temporal validity period was mishandled — the agent misattributes when the fact was true, or fails to notice that the fact is now outside its valid period. Unlike a stale cache issue, this is specifically about misreading or mismanaging the time-scoping of the fact itself: applying a 2019 regulatory limit as though it were still current in 2026, or applying a "current" fact to a past scenario the user is actually asking about.
Frequency:Common
An agent's retrieval step pulls two or more facts from different sources that directly contradict each other on the same question, and the agent proceeds to answer using one of them (often whichever appears first, scores marginally higher in relevance, or was retrieved last) without noticing, reconciling, or flagging the contradiction to the user. The user receives a confident single answer with no indication that the knowledge base itself disagrees on the point.
Frequency:Very Common
A knowledge base or cache stores facts indefinitely with no time-to-live (TTL) or expiration mechanism, so content that was accurate at ingestion time but has a known or implicit shelf life (prices, policies, personnel, regulatory limits) remains fully retrievable and presented with the same confidence as current content, indefinitely, unless someone manually removes or updates it. This is a systems-level gap rather than a per-fact error: the architecture itself has no concept of "this should stop being trusted after time T."
Frequency:Very Common
An agent applies a fact using an incorrectly assumed scope — the wrong jurisdiction, the wrong product version, the wrong organizational unit — because it never explicitly confirmed the scope the fact actually applies to versus the scope the user's situation is actually in. The fact is retrieved correctly and stated correctly for its true scope; the error is the silent assumption that the true scope matches the user's, when it may not.
Frequency:Very Common
A retrieval system treats every indexed source as equally trustworthy, with no mechanism to weight or rank content by the reliability of where it came from — an official, reviewed policy document is retrieved and used with exactly the same confidence as an unreviewed wiki page, a stale forum post, or a low-quality scraped page, simply because both matched the query with similar semantic relevance. When sources disagree or vary in quality, the system has no basis for preferring the more trustworthy one.
Frequency:Common
A source document explicitly scopes a fact with "as of" framing — "as of Q3 2025," "current as of the last policy revision," "prices shown are for the current promotional period" — but that framing is stripped during retrieval, summarization, or generation, leaving the agent's stated fact presented as timeless and universally current rather than tied to the specific moment the source actually anchored it to. The number or claim itself is preserved correctly; only the temporal anchor that made it interpretable is lost.
Frequency:Very Common
The system of record that an agent's knowledge base is supposed to reflect has been updated — a policy changed, a price changed, a product was discontinued — but the agent's indexed or cached copy has not caught up, because the ingestion/re-indexing pipeline runs on a cadence (scheduled batch job, manual trigger, event-driven pipeline with a backlog) that lags behind the actual rate of change at the source. The agent isn't wrong about what its knowledge base says; its knowledge base itself is behind reality.
Frequency:Very Common
An agent answers using knowledge tied to one version of a product, policy, or API — often the version most represented in its training data or knowledge base — while the user is actually working with a different version, and the two versions differ in ways that make the agent's answer wrong or actively harmful for the user's actual situation. The agent isn't confused about the fact itself; it's applying a fact that is correctly true for version N to a user who is on version N+1 or N-1, without checking or asking which version applies.
Knowledge freshness fails when an agent applies information that is true in isolation but wrong for the moment, scope, or domain-context it’s actually needed in — a fact that was accurate a year ago, a rule correctly quoted but misapplied to a case its exception covers, or a single retrieved sentence stripped of the qualifier that made it safe to act on. The 22 patterns documented here span three distinct levels of the same underlying problem: domain-level judgment that a generic retrieval pipeline doesn’t encode, single-fact distortions introduced during retrieval or generation, and system-level architecture gaps — no expiration mechanism, no update pipeline, no source-trust weighting — that make the other two levels of failure more likely. None of the 22 patterns require a hallucinated fact; every one is about a true fact applied at the wrong time, scope, or level of domain nuance.
Key Takeaways
- 22 patterns are documented here, the largest goal in knowledge retrieval, organized into domain-level misapplication (7), single-fact distortion (8), and system-level architecture gaps (7).
- Fact Context Loss and Fact Generalization Error are both rated “Very Common,” and an estimated 20-35% of agent responses summarizing multi-clause source documents omit at least one qualifier the source explicitly treats as load-bearing — completeness failures are common enough to be the default, not the exception.
- Domain Best-Practice Ignorance estimates a 6-18 month effective half-life for best-practice guidance in fast-moving technical domains, with 20-35% of “how should I do X” agent responses in actively-evolving domains referencing an approach practitioners now consider legacy.
- Knowledge Expiration Not Enforced documents a systems-level root cause behind many of the other 21 patterns: knowledge bases without any TTL or expiration mechanism retain an estimated 30-50% of ingested content well past its practical accuracy window within 18-24 months of launch.
Scope
- Domain-Level Misapplication — Domain Best-Practice Ignorance (GitHub), Domain Constraint Violation (GitHub), Domain Context Loss (GitHub), Domain Exception Not Handled (GitHub), Domain Risk Blindness (GitHub), Domain Rule Misunderstanding (GitHub), Domain Terminology Confusion (GitHub). An agent correctly retrieves domain knowledge but misapplies the domain-specific judgment layered on top of it — missing that a practice went stale, that a hard constraint applies, that an exception carves a case back in, that a fact combination is a red flag, that a rule’s scope boundary excludes a case, or that a term means something different in-domain than in general usage.
- Single-Fact Distortion — Fact Context Loss (GitHub), Fact Generalization Error (GitHub), Fact Inversion (GitHub), Fact Negation Confusion (GitHub), Fact Partial Truth (GitHub), Fact Probabilistic Mismatch (GitHub), Fact Source Confusion (GitHub), Fact Timestamp Error (GitHub). A single retrieved fact survives retrieval and generation correctly in its core content, but loses the qualifier, direction, negation, completeness, certainty level, entity attribution, or time-validity that made it correctly applicable.
- System-Level Freshness Architecture Gaps — Knowledge Contradiction Unresolved (GitHub), Knowledge Expiration Not Enforced (GitHub), Knowledge Scope Assumption Wrong (GitHub), Knowledge Source Reliability Unknown (GitHub), Knowledge Temporal Context Lost (GitHub), Knowledge Update Lag (GitHub), Knowledge Version Mismatch (GitHub). Architecture-level gaps in the knowledge base itself — no contradiction detection between retrieved passages, no expiration/TTL mechanism, no scope confirmation before answering, no source-reliability weighting, no “as of” preservation, no re-indexing speed matched to source change rate, no version tagging — that make individual fact-level and domain-level errors more likely to occur and go uncaught.
When Knowledge Freshness Matters
- An agent operates in a domain where best practice, regulation, or terminology shifts on a timescale shorter than the knowledge base’s re-verification cycle — security, medicine, tax, compliance, fast-moving engineering tooling
- A knowledge base mixes documents from multiple time periods, jurisdictions, product versions, or authority levels (official policy alongside team wikis or forum posts) with no explicit metadata distinguishing one from another
- Retrieved facts are compressed, summarized, or chunked before reaching generation, since qualifiers, exceptions, and “as of” framing are exactly the content most likely to be trimmed during compression
Cross-Pattern Insight
The throughline across all three levels of knowledge freshness is that standard fact-checking — does the stated claim match what the source says — is necessary but not sufficient, because every one of the 22 patterns describes a fact that is individually true and still produces a wrong outcome. Domain-level patterns fail because generic retrieval has no representation of domain-specific judgment (currency, hard constraints, exception carve-backs, risk salience) layered on top of literal fact accuracy. Single-fact patterns fail because compression and generation systematically strip the qualifying clause, direction, negation, or “as of” framing that made a true statement correctly scoped. System-level patterns fail because most knowledge base architectures are built to grow a corpus, not to manage its decay, with no default mechanism for expiration, contradiction detection, or source-trust weighting. The fix that recurs at every level is the same structural move: attach explicit metadata (currency tags, scope conditions, effective-date windows, source-reliability tiers) at ingestion time and enforce it as a first-class gate at retrieval or generation time, rather than trusting that semantic relevance or per-claim accuracy checking will catch a freshness problem it was never built to detect.
Frequently Asked Questions
What is the difference between a fact-level distortion and a domain-level misapplication?
A single-fact distortion (like Fact Inversion (GitHub) or Fact Context Loss (GitHub)) happens to one specific retrieved statement during retrieval or generation — the direction gets flipped, or a qualifying clause gets dropped. A domain-level misapplication (like Domain Exception Not Handled (GitHub) or Domain Rule Misunderstanding (GitHub)) happens even when every individual fact is retrieved and stated correctly — the error is in applying correct domain judgment (which exception governs, which scope boundary applies) on top of accurate facts.
How do you catch a fact that is accurate but incomplete?
Per Fact Partial Truth (GitHub), standard per-claim fact-checking won’t catch a partial-truth omission, since every stated claim passes verification against the source — the omission is invisible to methods built to catch commission (a false claim) rather than exclusion (a true but incomplete one). The documented fix is a dedicated completeness check that compares what the source says relevant to the query against what the response actually includes, rather than relying on accuracy scoring alone.
Does pinning a knowledge base to “the most recent document” solve staleness?
Not on its own. Knowledge Update Lag (GitHub) shows the index itself can lag the actual source-of-truth system regardless of how recency is weighted in ranking, and Knowledge Expiration Not Enforced (GitHub) shows that without an explicit TTL or deprecation mechanism, an old and a new version of the same fact can coexist as equally retrievable, with recency-weighting only helping if the freshness metadata itself is tracked and enforced.
Can a single retrieval pipeline fix knowledge scope errors across jurisdiction, version, and time simultaneously?
The mechanism is shared but the fix needs distinct metadata per scope dimension: Knowledge Scope Assumption Wrong (GitHub) covers jurisdiction/unit/version scope broadly, Knowledge Version Mismatch (GitHub) is the product-version-specific case, and Fact Timestamp Error (GitHub)/Knowledge Temporal Context Lost (GitHub) cover the time-validity case specifically. A single generic “check the scope” step won’t work without each dimension’s metadata (jurisdiction tags, version tags, effective-date windows) captured separately at ingestion.
What causes domain best practices to go stale even when the underlying facts stay true?
Per Domain Best-Practice Ignorance (GitHub), best practice is a “currently endorsed approach” judgment, not a truth judgment — a historically correct method can remain factually accurate while the field’s consensus moves past it, and no single retrieved passage contradicts the old advice, so ordinary fact-checking and consistency checks never flag the staleness. Only an explicit currency check against the domain’s current guidance catches it.
Patterns
| Pattern | Mechanism |
|---|
| Domain Best-Practice Ignorance (GitHub) | Retrieved advice was correct best practice at indexing time but has since been superseded by the field’s current consensus |
| Domain Constraint Violation (GitHub) | A hard regulatory or safety constraint loses the relevance-ranking competition against more topically prominent but non-binding content |
| Domain Context Loss (GitHub) | Domain framing established early in a session decays as the conversation grows, with nothing re-asserting it |
| Domain Exception Not Handled (GitHub) | A documented exception to a general rule is under-retrieved relative to the more prominent general rule it modifies |
| Domain Risk Blindness (GitHub) | A domain-standard risk pattern arising from a combination of facts isn’t flagged, even though each individual fact is stated correctly |
| Domain Rule Misunderstanding (GitHub) | A correctly-quoted rule is misapplied because compound or negated qualifying conditions are misread |
| Domain Terminology Confusion (GitHub) | A term with a specialized in-domain meaning is interpreted using its general-language sense instead |
| Fact Context Loss (GitHub) | A fact and its qualifying clause fall into separate chunks, so only the unqualified fact reaches generation |
| Fact Generalization Error (GitHub) | A narrowly-scoped fact (specific population, configuration, jurisdiction) is stripped of its scope and presented as a general truth |
| Fact Inversion (GitHub) | A fact’s direction or polarity is flipped during summarization, stating the opposite of the source |
| Fact Negation Confusion (GitHub) | A negation word is dropped, added, or misplaced during paraphrase, inverting a clause’s meaning |
| Fact Partial Truth (GitHub) | A response states only individually-accurate claims while omitting a qualifier that materially changes what a user should do |
| Fact Probabilistic Mismatch (GitHub) | A source’s probability or confidence framing is dropped, turning a likelihood into a stated certainty |
| Fact Source Confusion (GitHub) | Facts about two similarly-named entities are conflated because retrieval matched on name similarity rather than disambiguated identity |
| Fact Timestamp Error (GitHub) | A fact’s time-bound validity window is mismanaged, applying an outdated or future value as though currently valid |
| Knowledge Contradiction Unresolved (GitHub) | Two retrieved sources directly disagree and the response answers from one without noticing or disclosing the conflict |
| Knowledge Expiration Not Enforced (GitHub) | The knowledge base has no TTL or expiration mechanism, so content is retrievable indefinitely regardless of shelf life |
| Knowledge Scope Assumption Wrong (GitHub) | The system silently assumes a default jurisdiction, version, or unit instead of confirming the scope the user’s situation actually falls under |
| Knowledge Source Reliability Unknown (GitHub) | Every indexed source is treated as equally trustworthy, with no weighting distinguishing official content from unreviewed content |
| Knowledge Temporal Context Lost (GitHub) | An explicit “as of [date]” anchor from the source is stripped during generation, presenting a time-bound fact as timeless |
| Knowledge Update Lag (GitHub) | The re-indexing pipeline runs on a cadence slower than the source system’s actual rate of change |
| Knowledge Version Mismatch (GitHub) | An answer is scoped to whichever product/policy version dominates the knowledge base rather than the version the user is actually on |
Total: 22 patterns
- Retrieval Quality (GitHub) — Temporal Relevance and Index Staleness there share the update-lag and supersession mechanisms documented in depth across knowledge freshness’s system-level cluster
- Citation Accuracy (GitHub) — Misgrounded Citation is the citation-specific case of citing a source that’s been superseded, the same mechanism as Fact Timestamp Error and Knowledge Temporal Context Lost
- Answer Synthesis (GitHub) — Source Contradiction there is the generation-stage symptom of the same unresolved-conflict mechanism documented at the knowledge-base level in Knowledge Contradiction Unresolved