Evidence Freshness

Evidence has an expiration date. This guide explains why that matters and what to do about it.

Why Evidence Expires

Imagine you benchmarked Redis vs Memcached six months ago. Redis won. You made the decision, recorded the DRR, moved on.

Now it's six months later. The Memcached team shipped a major performance update. Your Node.js version changed. The benchmark numbers you relied on? They might not be accurate anymore.

The decision isn't necessarily wrong — it's just unverified.

This is what FPF calls Evidence Decay. Every piece of evidence has a valid_until date. When that date passes, the evidence is "stale" and the decisions built on it become questionable.

The Problem with Stale Evidence

Stale evidence creates hidden risk. You're operating on assumptions that haven't been re-checked. Maybe they're still true. Maybe they're not. You don't know.

Quint Code makes this visible instead of hiding it.

Checking Your Evidence

Run /fpf:decay to see what's stale:

/fpf:decay

You'll get a freshness report showing which holons have expired evidence:

## Evidence Freshness Report

### STALE (1 holon requires action)

#### Use Redis for Caching (L2)
| Evidence ID | Type | Status | Details |
|-------------|------|--------|---------|
| ev-benchmark-2024-06-15 | validation | EXPIRED | 180 days overdue |
| ev-load-test-2024-06-20 | validation | EXPIRED | 175 days overdue |

### FRESH (3 holons)
- Use TypeScript for API (L2)
- PostgreSQL for primary storage (L2)
- JWT for auth tokens (L2)

Three Ways to Handle Stale Evidence

When you see stale evidence, you have three options:

1. Refresh — Re-run the test

When: The decision is still correct, you just need fresh proof.

How: Run /fpf:propose-hypotheses run only validation step on the hypothesis to gather new evidence.

2. Deprecate — Reconsider the decision

When: The world has changed. The decision itself is questionable.

How: Tell the agent to deprecate the hypothesis. It gets downgraded one level (L2→L1 or L1→L0).

3. Waive — Accept the risk temporarily

When: You know it's stale, but you're shipping Tuesday and can't re-test everything right now.

How: Tell the agent to waive the evidence with a deadline and reason.

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 waiver goes in the audit log — who waived what, why, and until when.

Natural Language Usage

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

The agent sees the freshness report and understands context. When you say "waive the benchmark until February," it finds the right evidence ID and calls the tool for you.

These all work:

If you want to be explicit, you can:

But natural language works fine.

The WLNK Principle

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

This is the Weakest Link (WLNK) principle. If you have three pieces of evidence and one is stale, the whole decision is questionable. You don't get to average it out.

Think of it like a chain. Three strong links and one rusted link? The chain breaks at the rust.

Practical Workflows

Weekly Maintenance

Before a Release

After Major Changes

Dependency update? API change? Security advisory?

Audit Trail

All actions are logged:

Action
What's Recorded

Deprecate

from_layer, to_layer, who, when

Waive

evidence_id, until_date, rationale, who, when

You can always answer: "Who waived what and why?"

Last updated