Recovery Dashboard¶

Monitoring artifact — instantiates Recovery Trajectory Management

A single live view that aggregates recovery signals into function-restored status and surfaces who is still bearing the burden — so progress reads as validated function, not activity.

Version: v1 · 2026-08-24 · History
Mechanism #: 7164
Type: Monitoring Artifact
Form family: Monitoring, Sensing & Alerting
Solution family: Recovery & Restoration
Problem family: Fragility, Failure & Continuity Risk
Problem subfamily: Rollback, Reentry & Recovery Trajectory
Origin domain: Disaster Management & Risk Reduction
Also from: Data Science & Analytics, Public Administration & Policy
Instantiates: Recovery Trajectory Management

A Recovery Dashboard is the live, aggregated surface that lets everyone read the same picture of a recovery in near-real time. Its distinctive job is aggregation and legibility: it pulls signals from many restoration efforts into one view, renders each as function-restored status rather than task-completed status, and does so continuously while the recovery is in flight. It is not the thing that decides or validates — it is the thing that shows. Its second, easily-neglected panel tracks who is still bearing the burden: which populations remain unserved while the headline numbers improve. The dashboard exists to defeat the fragmentation of a big recovery, where each team knows its own slice and no one sees whether the whole trajectory is improving, plateauing, or hiding a group left behind.

Example¶

A metropolitan water utility is restoring service after a main break contaminates part of the distribution system, putting 180,000 residents under a boil-water advisory. Dozens of crews work in parallel: flushing mains, repairing the break, sampling for bacteria, restoring pressure zone by zone. The recovery dashboard is where the incident commander, the mayor, and the public see one coherent state. It renders each pressure zone by function restored — pressure normal, samples clear, advisory lifted — not by activity ("crews dispatched"). And it carries an equity panel: which neighborhoods are still under advisory, broken out so a low-income district on the system's edge cannot quietly stay on bottled water for a week after the wealthier core is cleared.

The payoff is a shared, honest read. When two consecutive sample rounds in one zone come back positive, the dashboard shows that zone stalling in red even as the citywide percentage climbs — and the equity panel keeps the last-served district visible instead of rounding it away. Everyone argues from the same board.

How it works¶

Aggregate many signals into one view. Ingest status from every restoration stream and compose it into a single, continuously-updated picture of the trajectory.
Render function, not activity. Define each tile as a function-restored state (validated, working) rather than a task-completed state, so "green" means the capability is back.
Show the trajectory's direction. Present improving / plateauing / relapsing over time, not just a point-in-time snapshot, so stalls and regressions are visible.
Keep a burden panel. Disaggregate remaining hardship by affected group so the last-served are never averaged out of view.

Tuning parameters¶

Aggregation grain — a single headline number versus per-zone, per-function tiles. Coarser views communicate fast but hide stalls; finer views are honest but busy.
Signal freshness — real-time streaming versus periodic refresh. Fresh data catches relapse quickly but can be noisy and expensive to plumb.
Function-vs-activity strictness — how firmly a tile is gated on validated function rather than reported activity. Strict gating prevents false greens but requires trustworthy validation upstream.
Equity disaggregation depth — how finely the burden panel breaks out affected groups. Finer breakdowns catch neglected populations but demand data that may be sensitive or missing.
Audience framing — an internal operational board versus a public-facing view. Public framing builds trust but pressures the display toward reassuring rounding.

When it helps, and when it misleads¶

Its strength is a shared, current, honest picture — and its two design commitments (function over activity, a standing burden panel) are aimed squarely at the archetype's traps of premature declaration and of recovery advancing on the backs of the least-served.

Its failure mode is the watermelon: green on the surface, red underneath — a dashboard whose tiles report activity dressed as function, so the board glows while the system is still broken. This is Goodhart's Law at work: once "percent restored" becomes the target everyone manages to, it stops measuring real recovery.^[n1] The classic misuse is a reassuring public dashboard that rounds the last-served district out of the headline. The guarding discipline is to gate tiles on validated function rather than self-reported activity, keep the burden panel un-averaged, and treat a too-smooth board as a prompt to check the underlying signal, not to relax.

How it implements the components¶

feedback_and_monitoring_signal — aggregates live restoration signals into a directional view (improving / plateauing / relapsing) rendered as function-restored status.
equity_and_burden_monitor — a standing panel that disaggregates remaining hardship by affected group so the last-served stay visible.

As a display surface it renders current signals but does not run the long-horizon function validation or slow-relapse surveillance of ecological recovery — recovery_validation_signal and residual_risk_watch belong to Ecological Restoration Monitoring Plan, its nearest monitoring twin. The dashboard shows many functions in near-real time for an active operation; the ecological plan samples a few indicators slowly against a reference and validates function itself.

Instantiates: Recovery Trajectory Management — this dashboard is the shared live surface for the recovery's monitoring and burden signals.
Consumes: Damage Assessment Survey and downstream restoration streams supply the signals the dashboard aggregates.
Sibling mechanisms: Ecological Restoration Monitoring Plan · Recovery After-Action Review · Community Recovery Plan · Phased Restoration Schedule · Service Restoration Runbook

Editorial Notes¶

Form Classification¶

Form family: Monitoring, Sensing & Alerting

Rationale: Recovery Dashboard operates as ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response because it a single live view that aggregates recovery signals into function-restored status and surfaces who is still bearing the burden — so progress reads as validated function, not activity.

Independent corroboration: The frozen evidence defines Recovery Dashboard as 'A single live view that aggregates recovery signals into function-restored status and surfaces who is still bearing the burden — so progress reads as validated function, not activity', so its operative form is Monitoring, Sensing & Alerting.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution¶

Primary origin: Disaster Management & Risk Reduction

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Function-restoration monitoring and burden tracking are central to disaster recovery management.

Related originating lineages:

Data Science & Analytics — Operational analytics supplies live aggregation and status visualization.
Public Administration & Policy — Public recovery governance materially shapes accountability for affected populations.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.