Risk Decay Dashboard¶
Metric / dashboard — instantiates Residual Risk Decay Tracking
Displays, at a glance and across cases, the current residual-risk signal, control level, elapsed time, and upcoming review for each case under staged control release.
A Risk Decay Dashboard is the shared display that makes the state of every open control-release case visible at a glance. For each case it renders the current residual-risk signal, the control level the case sits at, how long it has been there, and when its next review or release check falls due. Its defining idea is that it shows state, it does not compute or decide: it aggregates readings that other mechanisms produce and lays them out so a reviewer can see, in one view, which cases are decaying on track, which are overdue for a check, and which are stuck at a control level long past their risk. It is a window onto the present, not a forecast of the future and not a verdict.
Example¶
A county emergency-management office is managing re-entry after a wildfire that forced evacuations across a dozen zones. Each zone is a case with its own residual risk — air quality, structural hazards, active hotspots, restored utilities — decaying at its own rate. Deciding zone by zone in scattered spreadsheets and radio calls is how a zone gets reopened while a hotspot still smolders, or stays closed for weeks after it's safe. The Risk Decay Dashboard puts all twelve zones on one screen.
Each zone row shows its current residual-risk signal (air-quality index, hotspot count, structural-survey status — fed in from field teams), its present control level on the re-entry ladder (full evacuation / daytime-only access / open with advisory / normal), the elapsed time at that level, and the next scheduled inspection. Two zones flash: one is overdue for its structural survey, another has held "daytime-only" for a week though its signals have all cleared. The dashboard did not decide anything and computed no decay curve — the field teams measured the signals, the ladder defined the levels. It made the state of the whole operation legible so the incident commander could see, in one glance, where attention was owed.
How it works¶
- Ingest the signals. Pull the current residual-risk readings for each case from the field, sensors, or systems that produce them; the dashboard is a consumer of these, never their source.
- Show the control level. For each case, display which rung of the control ladder it currently occupies, so proportionality between risk and control is visible.
- Surface the cadence. Render elapsed time at the current level and the next scheduled review or release check, so overdue and stalled cases stand out.
- Sort by attention owed. Order and flag cases by what needs a human — overdue checks, cleared-but-still-restricted, signals worsening — turning a data table into a triage view.
Tuning parameters¶
- Refresh latency — how fresh the displayed signals are. Real-time feeds catch fast-moving risk but cost integration and can flicker; periodic refresh is simpler but can show stale state.
- Aggregation vs. drill-down — how much each case is summarized on the top view versus expandable. Heavy summarization scans fast but hides nuance; deep drill-down is thorough but slow to read.
- Flagging thresholds — what conditions light a case up (overdue, cleared-but-held, worsening). Sensitive flags surface issues early but can wash the board in color; blunt flags keep it calm but bury slow problems.
- Scope of view — one case in depth versus a whole portfolio at a glance. Portfolio views aid triage across cases; single-case views aid a specific decision.
When it helps, and when it misleads¶
The dashboard is invaluable when many cases are under staged release at once and the risk is losing track — a case reopened too early, or forgotten at a high control level long after its risk decayed. By making elapsed time and current level visible together, it directly attacks the archetype's twin failures of premature release and indefinite restriction.
Its danger is Goodhart's law[n1]: once a dashboard metric becomes the target everyone manages to, the metric stops measuring what it was meant to. A "days-at-level" or "cases-cleared" tile can be optimized — cases nudged down a level to make the board look green — until the display flatters the operation instead of describing it. It also invites the false comfort that a legible dashboard is a governed process; a beautiful display of the wrong signals is still blindness. The guarding discipline is to remember the dashboard only shows state — the judgment still belongs to a review — and to keep its signals honest proxies for real risk rather than numbers that are easy to move.
How it implements the components¶
residual_risk_signal— its core content is the current risk reading per case, surfaced for the reviewer to see.control_intensity_ladder— it displays which control level each case currently occupies, making risk-to-control proportionality visible at a glance.monitoring_cadence— it shows elapsed time and the next scheduled check, surfacing overdue and stalled cases.
This dashboard displays current state; it does not implement risk_decay_curve, risk_classification_scheme, or uncertainty_buffer — computing the projected decline and its confidence band for a class of cases is Fraud Risk Decay Model, whose output a dashboard may render but does not produce.
Related¶
- Instantiates: Residual Risk Decay Tracking — the dashboard is how the state of many staged-release cases is made visible and triageable.
- Consumes: Post-Incident Monitoring Plan defines which signals and cadence the dashboard renders for each case.
- Sibling mechanisms: Fraud Risk Decay Model · Post-Incident Monitoring Plan · Control Release Review · Access Restoration Ladder · Probation Review Schedule · Release Threshold Checklist
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: Risk Decay Dashboard operates as ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response because it displays, at a glance and across cases, the current residual-risk signal, control level, elapsed time, and upcoming review for each case under staged control release.
Independent corroboration: The frozen evidence defines Risk Decay Dashboard as 'Displays, at a glance and across cases, the current residual-risk signal, control level, elapsed time, and upcoming review for each case under staged control release', so its operative form is Monitoring, Sensing & Alerting.
Nearest alternative: Interface, Display & Cue — Risk Decay Dashboard includes features of a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use, but its defining operation is ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Tracking whether residual risk actually declines after treatment extends engineering risk retirement and closure practice into a time-series control display. Systems monitoring, emergency recovery, and program oversight contribute feedback cadence and accountability.
Related originating lineages:
- Disaster Management & Risk Reduction — disaster_management contributes preparedness, continuity, hazard containment, and recovery practice to the mechanism’s formative or independently convergent form; that contribution does not displace the primary engineering_design lineage.
- Public Administration & Policy — public_administration_policy contributes program oversight, public allocation, implementation, and continuity obligations to the mechanism’s formative or independently convergent form; that contribution does not displace the primary engineering_design lineage.
- Systems Thinking & Cybernetics — systems_cybernetics contributes feedback, perturbation, dynamic role change, and interconnected risk behavior to the mechanism’s formative or independently convergent form; that contribution does not displace the primary engineering_design lineage.
Review resolution: The blind reviewers disagreed on primary lineage (engineering_design versus disaster_management); authoritative or primary research supports engineering_design as the best historical origin. Tracking whether residual risk actually declines after treatment extends engineering risk retirement and closure practice into a time-series control display. Systems monitoring, emergency recovery, and program oversight contribute feedback cadence and accountability. The cited NASA Risk Management Requirements and Definitions; NIST Risk Management Framework: Monitor Step directly supports the defining operation used in that choice. All independently supported contributing domains are retained without an arbitrary cap, while domain_reach=multi_domain records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
Notes¶
The near-name twin is the Fraud Risk Decay Model, and the divide is display vs. compute. The dashboard shows the current state — live signals, present control level, next check — across many cases. The model computes a projected decay curve and its uncertainty for a class of cases. A dashboard can put a model's curve on screen, but rendering a number is not producing it; the dashboard holds no decay function of its own.
[n1] Goodhart's law — "when a measure becomes a target, it ceases to be a good measure." A risk-decay dashboard's tiles are prime candidates: once staff manage to the green board rather than to actual risk, the display can look healthy while the underlying process degrades. ↩