#Evidence Decay & Epistemic Debt

B.3.4 · Stable · Part B - Trans-disciplinary Reasoning Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Use this when. An earlier result is being relied on now, and a changed condition or a due review may change whether it still supports the receiving claim. Begin with the relied-on use and the premise that may have changed.

#Keywords

• evidence currentness
• age
• changed premise
• qualification window
• refresh
• epistemic debt.

#Relations

#Content

#Problem Frame

Use this when. An earlier result is being relied on now, and a changed condition or a due review may change whether it still supports the receiving claim. Begin with the relied-on use and the premise that may have changed.

A bridge's earlier assessment may remain applicable to its unchanged bounded use, while a new traffic load defeats that assessment before its scheduled review. A library result can remain applicable to unchanged dependencies yet fail to address a newly discovered relevant vulnerability. The age of either report does not distinguish these cases.

Practical gain. Reconsider the affected support in time to change the decision, while retaining useful results whose relevant premises still hold.

Ordinary boundary. Do not open a new assurance procedure solely because a carrier is older. If available information already establishes applicability for the immediate use, continue on that basis without a renewal or skip-refresh certificate. A real licence deadline, calibration qualification or promised-use window remains a condition of the actual use.

#Problem

How can a team notice obsolete support without treating elapsed time as automatic loss of truth, measured risk growth or loss of every use of an evidence carrier?

Three failures matter: a changed load-bearing premise remains unnoticed; a fresh but irrelevant result creates false reassurance; or repeated checks of unchanged premises displace protective maintenance that could actually change the outcome.

#Forces

#Solution

Qualify currentness at the claim and receiving use. Reconsider only the dependency reach for which a changed premise or an applicable review rule can alter the conclusion.

#Locate the condition that can change reliance

Identify the earlier result being used and the relevant conditions: for example, its configuration, operating envelope, measurement qualification or dependency. Establish whether available information still supports those conditions. An unchanged file is not proof that its environment is unchanged; an older file is not proof that its support has failed.

Use time-based review when an applicable deterioration model or review policy warrants it. Use event-, dependency- or condition-based reconsideration when those define applicability. A newly discovered failure mode may reopen a result before a review date. A calendar reminder may instead find that the result remains applicable without a new experiment.

Keep three judgements distinct: whether the earlier evidence applies, whether it is sufficient for the present claim, and whether the proposed action satisfies its actual conditions. Currentness alone answers neither sufficiency nor permission.

#Give dates their actual meaning

A valid_until: ISO-8601-date | null field is used only when the receiving claim or applicable rule has a calendar boundary to convey. State what the date bounds. A review-due date requests reconsideration; a qualification, right or resource-use end date can terminate an allowed use. Do not merge these meanings into a global expiry of the carrier.

An absent or null date means that this field supplies no calendar boundary. It asserts neither perpetual validity nor invalidity and creates no mandatory justification for a missing date. Applicable event or condition limits still govern the use.

Where a required review period applies, follow it until it is changed by someone with the necessary authority. Evaluate its protective purpose, threshold basis and displaced cost separately when deciding whether to propose that change. Questioning the policy is not permission to ignore it.

#Treat epistemic debt as an optional planning indicator

A team may call its outstanding evidence-review or maintenance obligations epistemic debt (ED). If it needs a number, define the counted entities, dependency treatment, scale and unit, policy purpose, and meaning of the action threshold. An epistemic_debt_budget is then a named planning-policy limit, not a universal allowance of harm.

For example, a team may count distinct overdue review obligations to plan assessor capacity. Ten duplicate paths to one obligation do not create ten obligations. Separate obligations consuming the same source may still require different judgements for different uses.

Elapsed days can contribute to a justified priority rule or deterioration model. B.3.4 supplies no default rate, sum or automatic level downgrade. A planning count is not a probability of failure, and zero overdue reviews does not establish an adequate assurance case.

#Choose the feasible response to the actual change

Determine what the receiving use can support now. The following are possible responses, not a compulsory completion triad:

C.11 and C.19.2 supply the choice of worthwhile additional evidence. Rechecking available configuration or premise information need not be a new experiment. A possible experiment is not a Work commitment. If the desired check is unavailable, retain any independently warranted bounded action or limitation; do not fabricate an observation.

For an immediate unchanged use, stop with its usable result. When a later receiver needs a warning, limitation or retained reason to avoid unsupported reliance, keep that minimum content with the existing result or publication. A separate DeprecationNotice is useful when something is actually deprecated, not as proof that refresh was skipped.

#Follow affected dependencies and preserve real expiry

Trace a changed premise to the claims and uses that actually depend on it. Reopen those conclusions under their applicable evidence model. Shared paths do not multiply evidence or risk, and an unaffected use does not inherit a global downgrade from the carrier's age.

Keep actual physical and institutional conditions intact. Expired calibration qualification, an unavailable configuration, ended resource support or an elapsed rights window can block the corresponding use even when the old report remains an accurate record of an earlier state. A justified deterioration model can make elapsed time material; cite that model rather than inferring universal decay.

A dashboard should distinguish a review due, a defeated premise and a restricted use. Its colour reports the declared indicator or disposition, not the truth of the underlying claim. A failing test is a potentially relevant adverse result to assess now, not merely another overdue date.

#Worked cases: the same age, different decisions

Bridge. An earlier structural assessment supports a specified load envelope, conditional on its stated condition and inspection regime. For an unchanged limited use, available load and condition information and satisfied required inspections can preserve that support. The assessment's age alone adds no repeat assessment. In the paired case, proposed traffic exceeds the envelope: the earlier report does not support that use, however recent its cover date. Obtain the assessment or restriction needed for the changed load before relying on the stronger claim.

Suppose the available inspection team can either inspect a suspected load-bearing defect or repeat an already adequate check whose relevant conditions remain established. Examine the protected harm and the basis of the inspection requirement, what each result could change, and the cost of delay. Where the defect inspection can prevent that harm and the repeat adds no useful information, preserve the inspection capacity. If a currently binding repeat requirement prevents that choice, seek an authorized amendment; the resource conflict does not itself remove the requirement.

Library. The verified property of an unchanged library in its qualified configuration remains supported when the relevant assumptions and dependencies still hold. A new vulnerability affecting a dependency used by the security claim reopens that claim even before a review date. An unrelated vulnerability does not. Preserve unaffected functional results and any independently supported restricted service while addressing the security limitation. A release recipient who would otherwise assume the affected security property needs that limitation in the released result.

#Conformance Checklist

• CC-ED.1 (Use-qualified currentness): A currentness conclusion MUST identify the relied-on claim/use and the conditions or temporal boundary that change it. A carrier's age or absent date SHALL NOT alone establish loss of support.
• CC-ED.2 (Interpreted planning measure): A numerical ED or debt budget MUST define its counted entities, dependency treatment, scale/unit, purpose and threshold meaning. No project has a default obligation to adopt one.
• CC-ED.3 (Affected reach): Reconsideration MUST follow the actual support dependencies. Any aggregation MUST use an applicable interpreted model and avoid counting duplicate paths as additional evidence or risk.
• CC-ED.4 (Qualified disposition): A trigger MUST be interpreted for the receiving use; it SHALL NOT automatically downgrade a level or require Refresh/Deprecate/Waive. Preserve a sufficient current result without a separate renewal or no-refresh certificate. Preserve real qualification, rights and resource-use expiry.
• CC-ED.5 (Actual exception authority): A waiver, when used, MUST have the authority and scope allowed by the applicable rule, a rationale, affected risk bearers and accountability, and its actual ending or reconsideration condition. Keep the auditable exception with the decision that uses it; a title or lowered assurance status does not confer risk-acceptance authority.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Teams can retain applicable support and direct review towards changed premises, reducing needless repetition without losing actual maintenance obligations. Later recipients receive the warnings that change their decisions.

This requires judgement about dependency reach and review policy. An optional queue or dashboard helps allocate capacity but cannot replace that judgement. Sparse evidence about a relevant condition may leave the current use unresolved even when the carrier itself is unchanged.

#Rationale

An earlier result can remain valid for its earlier claim while no longer supporting a changed use. Conversely, elapsed time need not defeat an unchanged premise. Maintenance therefore follows the assurance argument and its conditions rather than a universal entropy metaphor.

B.3's source account and ISO/IEC/IEEE 15026-2:2022 place maintenance with assurance cases. C.27.TA supplies the use-relative temporal qualification. This pattern adapts those distinctions to continued reliance and planning; it attributes no universal decay equation or mandatory expiry date to the standard. A validated domain deterioration model or an applicable review rule can justify a particular time-based policy and its reconsideration conditions.

#Relations

• B.3 and B.3.3: define the assurance claim, receiving use and any justified local level profile.
• A.10 and C.27.TA: supply evidence-use dependencies and qualified temporal claims.
• G.11: schedules justified reconsideration or refresh over the affected dependency slice and conveys needed limitations to later recipients.
• C.11 and C.19.2: support the choice of obtainable evidence work when its contribution can change the decision.
• B.4: uses actual transition conditions; a debt indicator does not constitute its evolution gate.
• Part D and applicable domain rules: govern protected interests, authority and exceptions; an assurance status change does not decide them.

#B.3.4:End

---

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)