Evidence Freshness
Evidence has an expiration date. This guide explains why that matters and what to do about it.
Overview
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 /decay to see what's stale:
/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 /propose-hypotheses run only validation step on the hypothesis to gather new evidence.
User: The Redis benchmark is old but Redis is still the right choice.
Refresh the evidence.
Agent: Running validation for hypothesis-redis-caching...
[executes benchmark]
Evidence refreshed. Valid until 2025-06-21.
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).
User: AWS announced they're deprecating this service.
Deprecate that decision.
Agent: Deprecated: hypothesis-aws-service L2 → L1
This decision now needs re-evaluation.
Run /q1-hypothesize to explore alternatives.
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.
User: We're launching next week. Waive the benchmark until January 15th,
we have a full test cycle scheduled for the 20th.
Agent: Waiver recorded:
- Evidence: ev-benchmark-2024-06-15
- Waived until: 2025-01-15
- Rationale: Launch deadline. Full test cycle Jan 20.
Warning: Returns to EXPIRED after 2025-01-15.
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:
"Waive everything until January 15th, we're launching"
"The load test is only 2 weeks overdue, refresh it"
"That API is being deprecated, deprecate our decision to use it"
"Waive the security audit until the 15th with rationale: re-audit scheduled"
If you want to be explicit, you can:
/decay --waive ev-benchmark-2024-06-15 --until 2025-02-01 --rationale "Migration pending"
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
/decay # What's stale?
# For each item: refresh, deprecate, or waive
Before a Release
/decay # Check for stale decisions
# Either refresh evidence or explicitly waive with rationale
# Waivers become part of release documentation
After Major Changes
Dependency update? API change? Security advisory?
/decay # What's affected?
# Deprecate obsolete decisions
# Start new hypothesis cycle for replacements
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?"