Stats
Actions
Tags
From fpf
Generates FPF evidence freshness reports identifying stale/expired items and supports refresh, deprecate, or waive actions for governance.
How this skill is triggered — by the user, by Claude, or both
Slash command
/fpf:decayThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Manages **evidence freshness** by identifying stale decisions and providing governance actions. Implements FPF B.3.4 (Evidence Decay).
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.
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.
Waiving = "I know this evidence is stale, I accept the risk temporarily."
Use it when:
A waiver is NOT ignoring the problem - it's explicitly documenting that you know about the risk and accept it until a specific date.
| 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 |
.fpf/evidence/valid_until from frontmatter## Evidence Freshness Report
### EXPIRED (Requires Action)
| Evidence | Hypothesis | Expired | Days Overdue |
|----------|------------|---------|--------------|
| ev-benchmark-2024-06-15 | redis-caching | 2024-12-15 | 45 |
| ev-security-2024-07-01 | auth-module | 2025-01-01 | 14 |
### STALE (Warning)
| Evidence | Hypothesis | Expires | Days Left |
|----------|------------|---------|-----------|
| ev-loadtest-2024-10-01 | api-gateway | 2025-01-20 | 5 |
### FRESH
| Evidence | Hypothesis | Expires |
|----------|------------|---------|
| ev-unittest-2025-01-10 | validation-lib | 2025-07-10 |
### WAIVED
| Evidence | Waived Until | Rationale |
|----------|--------------|-----------|
| ev-perf-old | 2025-02-01 | Migration pending |
Based on user response, perform one of:
User: "Refresh the redis caching evidence"
.fpf/knowledge/L2/User: "Deprecate the auth module decision"
# 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
mv .fpf/knowledge/L2/auth-module.md .fpf/knowledge/L1/auth-module.md
User: "Waive the benchmark until February"
# 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.
You don't need to memorize evidence IDs. Just describe what you want.
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.
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.
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}.mdwaiver-{evidence}-{date}.md/fpf:decay # See what's stale
# For each stale item: refresh, deprecate, or waive
/fpf:decay # Check for stale decisions
# Either refresh evidence or explicitly waive with documented rationale
# Waiver rationales become part of release documentation
# Dependency update, API change, security advisory...
/fpf:decay # See what's affected
# Deprecate obsolete decisions
# Start new hypothesis cycle for replacements
npx claudepluginhub neolabhq/context-engineering-kit --plugin fpfAudits git changes against FPF knowledge base to detect config drift, stale evidence, outdated decisions, and update baseline in .fpf/. Useful after repo updates in FPF projects.
Tracks provenance and freshness of findings in .first-plan/ with source, TTL, confidence decay, and supersedence chain. Use during discovery and refresh to prevent stale facts.
Generates freshness reports for secondbrain entities like ADRs, tasks, notes, and discussions, categorizing by staleness levels with summaries, tables, and remediation actions.