Half-life decay for RAG: how to weight ageing knowledge

Half-life decay is a way to prefer newer retrieval results, not a way to establish which result is correct. For team knowledge, we recommend treating age as one ranking signal alongside explicit decision status and evidence about when a statement applies. An old decision can still govern today's system, while a new conversation can describe an idea nobody has accepted.

The distinction matters when an agent asks what to build now rather than what the team once discussed. Our recommended starting point is to record replacements explicitly, then test whether time weighting improves retrieval for the remaining ambiguous cases.

Retrieval needs a question about time

The TimeR4 research paper tackles temporal knowledge graph questions by retrieving facts that match both meaning and time constraints. Its framework rewrites questions with temporal information, retrieves again and reranks against those constraints. That is a specialised research method, not evidence that adding a half-life to a team's document search will produce the same results.

For an engineering knowledge base, separate questions about the current implementation from questions about an earlier release. We recommend making that distinction explicit in the retrieval request rather than applying a preference for recent material to every question. A query about why a retired authentication mechanism was chosen needs the earlier reasoning, not merely the latest replacement notice.

Multiply relevance by a decay factor

For a simple half-life experiment, we propose this calculation:

decay = 0.5 ** (age_days / half_life_days)
weighted_score = relevance_score * decay

Here, ** means exponentiation, age_days is a non-negative age and half_life_days must be positive. The second line multiplies relevance by decay rather than adding the decay factor to the score. With a hypothetical half-life of 90 days, the factors at ages of zero, 90 and 180 days are 1, 0.5 and 0.25. At 360 days, the factor is 0.0625. These are arithmetic examples, not measured improvements or a statement of Dendro Logic's internal configuration.

Suppose an older document has relevance 0.9 and is 180 days old, while a document dated today has relevance 0.6. Under that hypothetical 90-day setting, their weighted scores are 0.225 and 0.6 respectively. The newer document ranks higher under this rule, but nothing in the calculation checks its authority or factual accuracy.

Use a score where larger, non-negative values mean greater relevance before applying this example. Multiplying a negative score by a factor below one moves it towards zero, so blindly applying this rule to signed similarities can reverse the intended penalty. Check how your retriever represents distance or similarity and test the transformation before comparing results.

Choose half-lives through evaluation

We suggest comparing no decay with a small number of explicitly hypothetical settings, such as 90 days and 365 days. Those values are experiment settings, not recommended defaults for every organisation or content category. Evaluate operational notes separately from accepted decisions and reference documents.

For a current-state query, consider stronger age penalties for provisional notes only if your test cases support that choice. For a stable specification, consider no decay and select the applicable version explicitly. A document's category should help define the experiment, not substitute for evidence about whether that document still applies.

Apply status, scope and permission checks before comparing candidate scores. If decay is only a reranking step, it cannot retrieve a current document that the first search never returned. Inspect candidate retrieval as well as the final ordering when a replacement remains missing from the answer.

Supersession is different from age

Michael Nygard's original ADR guidance recommends keeping reversed decisions, marking them superseded and referring to their replacements. For agent retrieval, we recommend recording the replacement identifier and the date it became effective alongside the old decision's status. For questions about current practice, exclude superseded guidance from the actionable answer or label it clearly as history.

For historical questions, retrieve the version that applied at the requested time and preserve the link to what replaced it. Do not delete old reasoning merely because it receives a lower current-work ranking. A useful acceptance case is an older accepted decision competing with a newer rejected proposal, where the accepted decision should remain authoritative. That case tests a failure that age weighting alone cannot resolve.

A timestamp needs a defined meaning

We recommend storing source publication, substantive revision and ingestion times separately where they are available. Treat an effective date as distinct from all of them. If a document is re-imported today without a substantive change, using ingestion time as its age origin would make unchanged material appear new under this formula. Likewise, a formatting edit should not automatically renew the validity of every statement in a document.

Document which timestamp drives ranking and how it is inherited by extracted chunks. When dates are missing, record them as unknown rather than silently substituting the current time. Flag future timestamps for review and define a consistent timezone and age policy. Keep the source version and timestamp visible in the evidence passed to the agent so a reviewer can inspect the ranking's inputs.

Test the answer, not only the ordering

Build a labelled test set with current decisions, superseded decisions, unchanged reference material and explicit historical questions. Include missing timestamps, re-imported documents and a newer but incorrect note. Compare the same questions with and without decay while holding the candidate set and generation settings constant. Then test the whole retrieval pipeline, because a controlled reranking comparison does not test missing candidates.

Measure whether the applicable evidence appears in the retrieved results and whether the final answer cites that evidence correctly. Inspect cases where historical evidence disappears or an unapproved note displaces an accepted decision. Keep a record of regressions and choose settings against the failures your team can tolerate. We recommend retaining no decay as a baseline rather than assuming that a more recent answer is a better one.

Update, October 2026

Our later engineering article on resumption-first memory design discusses keeping source pointers in memory items and treating summaries as an index to original conversations. For an ageing policy, that offers a useful review question: can the agent recover the original evidence after ranking and summarisation?

Sources

• Qian and colleagues, "TimeR4: Time-aware Retrieval-Augmented Large Language Models for Temporal Knowledge Graph Question Answering", November 2024.
• Michael Nygard, "Documenting Architecture Decisions", 15 November 2011.