Evidence Freshness Management

Manages evidence freshness by identifying stale decisions and providing governance actions. Implements FPF B.3.4 (Evidence Decay).

Key principle: Evidence is perishable. Decisions built on expired evidence carry hidden risk.

Quick Concepts

What is "stale" evidence?

Every piece of evidence has a valid_until date. A benchmark from 6 months ago may no longer reflect current system performance. A security audit from before a major dependency update doesn't account for new vulnerabilities.

When evidence expires, the decision it supports becomes questionable - not necessarily wrong, just unverified.

What is "waiving"?

Waiving = "I know this evidence is stale, I accept the risk temporarily."

Use it when:

• You're about to launch and don't have time to re-run all tests

• The evidence is only slightly expired and probably still valid

• You have a scheduled date to refresh it properly

A waiver is NOT ignoring the problem - it's explicitly documenting that you know about the risk and accept it until a specific date.

The Three Actions

Situation Action What it does

Evidence is old but decision is still good Refresh Re-run the test, get fresh evidence

Decision is obsolete, needs rethinking Deprecate Downgrade hypothesis, restart evaluation

Accept risk temporarily Waive Record the risk acceptance with deadline

Action (Run-Time)

Step 1: Generate Freshness Report

• List all evidence files in .fpf/evidence/

• For each evidence file:

• Read valid_until from frontmatter

• Compare with current date

• Classify as FRESH, STALE, or EXPIRED

Step 2: Present Report

Evidence Freshness Report

EXPIRED (Requires Action)

STALE (Warning)

FRESH

WAIVED

Step 3: Handle User Actions

Based on user response, perform one of:

Refresh

User: "Refresh the redis caching evidence"

• Navigate to the hypothesis in .fpf/knowledge/L2/

• Re-run validation to create fresh evidence

Deprecate

User: "Deprecate the auth module decision"

• Move hypothesis from L2 to L1 (or L1 to L0)

• Create deprecation record:

In .fpf/evidence/deprecate-auth-module-2025-01-15.md

id: deprecate-auth-module-2025-01-15 hypothesis_id: auth-module action: deprecate from_layer: L2 to_layer: L1 created: 2025-01-15T10:00:00Z

Deprecation: auth-module

Reason: Evidence expired, technology landscape changed

Next Steps: Run /fpf:propose-hypotheses to explore alternatives

• Move the hypothesis file:

mv .fpf/knowledge/L2/auth-module.md .fpf/knowledge/L1/auth-module.md

Waive

User: "Waive the benchmark until February"

• Create waiver record:

In .fpf/evidence/waiver-benchmark-2025-01-15.md

id: waiver-benchmark-2025-01-15 evidence_id: ev-benchmark-2024-06-15 waived_until: 2025-02-01 created: 2025-01-15T10:00:00Z

Waiver: ev-benchmark-2024-06-15

Evidence: ev-benchmark-2024-06-15 Hypothesis: redis-caching Waived Until: 2025-02-01 Rationale: Migration pending, will re-run after completion

Accepted By: User Created: 2025-01-15

WARNING: This evidence returns to EXPIRED status after 2025-02-01.

Natural Language Usage

You don't need to memorize evidence IDs. Just describe what you want.

Example Workflow

User: /fpf:decay

Agent shows report with stale evidence

User: Waive the benchmark until February, we'll re-run it after the migration.

Agent: Creating waiver for ev-benchmark-2024-06-15 until 2025-02-01. Rationale: "Re-run after migration"

   [Creates .fpf/evidence/waiver-benchmark-2025-01-15.md]

User: The vendor API is being discontinued. Deprecate that decision.

Agent: Deprecating hypothesis-vendor-api from L2 to L1. [Moves file, creates deprecation record]

   Next step: Run /fpf:propose-hypotheses to explore alternatives.

WLNK Principle

A hypothesis is STALE if any of its evidence is expired (and not waived).

This is the Weakest Link (WLNK) principle: reliability = min(all evidence). One stale piece makes the whole decision questionable.

Audit Trail

All actions are logged:

Action What's Recorded

Deprecate from_layer, to_layer, reason, date

Waive evidence_id, until_date, rationale, date

Files created in .fpf/evidence/ :

• deprecate-{hypothesis}-{date}.md

• waiver-{evidence}-{date}.md

Common Workflows

Weekly Maintenance

/fpf:decay # See what's stale

For each stale item: refresh, deprecate, or waive

Pre-Release

/fpf:decay # Check for stale decisions

Either refresh evidence or explicitly waive with documented rationale

Waiver rationales become part of release documentation

After Major Change

Dependency update, API change, security advisory...

/fpf:decay # See what's affected

Deprecate obsolete decisions

Start new hypothesis cycle for replacements