Decay
Govern decision records when supporting evidence has expired so shipping and ops choices are not based on stale benchmarks or audits.
Overview
Decay is an agent skill most often used in Operate (also Ship, Grow) that manages evidence freshness by flagging stale decisions and guiding Refresh, Deprecate, or Waive governance actions.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill decayWhat is this skill?
- Maps FPF B.3.4 evidence decay to three governance actions: Refresh, Deprecate, and Waive
- Treats expired valid_until evidence as questionable decisions rather than silently trusting old proof
- Documents temporary risk acceptance with explicit waivers and a planned refresh date
- Separates “re-run proof” (Refresh) from “rethink the decision” (Deprecate)
- Surfaces hidden risk when benchmarks, audits, or test results are no longer current
- Implements FPF B.3.4 Evidence Decay
Adoption & trust: 511 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have documented decisions backed by dated benchmarks or audits, and you cannot tell which choices are still verified versus carrying hidden expiry risk.
Who is it for?
Solo builders maintaining FPF-style or markdown decision/evidence trails who need a repeatable ritual before launches or quarterly reviews.
Skip if: Teams with no recorded evidence dates or valid_until metadata who only want a one-off linter with no governance narrative.
When should I use this skill?
Supporting evidence for an active decision may be past valid_until or before a major launch or dependency change.
What do I get? / Deliverables
After running Decay, stale evidence is classified with an explicit next action—refresh proof, deprecate the decision, or waive with a documented deadline—so downstream work does not assume expired data is still true.
- Classified stale-evidence list with recommended Refresh, Deprecate, or Waive actions
- Optional waiver notes with accepted risk until a refresh date
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Operate because freshness decay is an ongoing production-governance problem after decisions are already in play. Iterate fits recurring review of which decisions still have valid evidence versus which need refresh, waive, or deprecate.
Where it fits
Before release, list security audits whose valid_until passed after a dependency bump and Refresh or Waive with a dated follow-up.
During a monthly ops review, Deprecate architecture decisions whose load-test evidence expired six months ago.
Check whether growth experiments still rely on CAC or funnel benchmarks that are past valid_until and refresh measurement.
When prioritizing backlog, downgrade roadmap bets tied to stale competitive research evidence.
How it compares
Use instead of ignoring audit dates in READMEs or treating old test output as forever valid without a waiver record.
Common Questions / FAQ
Who is decay for?
Decay is for indie builders and small teams using structured decision logs (especially FPF or context-engineering workflows) who must know when proof behind a choice has expired.
When should I use decay?
Use decay during Operate iteration before scaling traffic, after major dependency upgrades in Ship security reviews, and in Grow when campaign or performance claims still cite old measurements.
Is decay safe to install?
Review the Security Audits panel on this Prism page and inspect the skill bundle in your repo before granting filesystem or shell access to archive or move knowledge files.
SKILL.md
READMESKILL.md - Decay
# 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 1. List all evidence files in `.fpf/evidence/` 2. For each evidence file: - Read `valid_until` from frontmatter - Compare with current date - Classify as FRESH, STALE, or EXPIRED ### Step 2: Present Report ```markdown ## 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 | ``` ### Step 3: Handle User Actions Based on user response, perform one of: #### Refresh User: "Refresh the redis caching evidence" 1. Navigate to the hypothesis in `.fpf/knowledge/L2/` 2. Re-run validation to create fresh evidence #### Deprecate User: "Deprecate the auth module decision" 1. Move hypothesis from L2 to L1 (or L1 to L0) 2. Create deprecation record: ```markdown # 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 ``` 3. Move the hypothesis file: ```bash mv .fpf/knowledge/L2/auth-module.md .fpf/knowledge/L1/auth-module.md ``` #### Waive User: "Waive the benchmark until February" 1. Create waiver record: ```markdown # 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