Dashboards should follow decisions
A dashboard is useful only if it helps someone decide whether to promote, rollback, retire, investigate, or hold no-op. Avoid vanity charts.
Core dashboard groups
| Dashboard | Key questions |
|---|---|
| Population health | Is the active population covering the workload without bloat? |
| Viability | Are recent changes repaying their cost? |
| Release quality | Are canaries, rollbacks, and incidents within limits? |
| Cost and capacity | Are memory, latency, compute, and energy sustainable? |
| Drift | Has the environment moved enough to reopen breeding? |
| Safety | Are hard gates, permissions, and red-team findings clean? |
| Human capability | Are users becoming stronger or more dependent? |
Minimum KPI list
KPI_SET ModelBreederOperations
active_module_count
candidate_count
archived_elite_count
p95_latency_by_route
memory_residency_by_module
cost_per_successful_task
wrong_route_rate
escalation_rate
calibration_error
failure_correlation
rollback_rate
canary_stop_rate
unresolved_hard_gate_count
user_exit_success_rate
reduced_assistance_capability_score
END KPI_SETAlert thresholds
Alert only when someone can act. A high wrong-route rate should create a router investigation. A rising memory residency should trigger population pruning. A falling reduced-assistance score should trigger anti-dependency review.
Dashboard anti-patterns
Do not make benchmark score the only hero metric. Do not hide cost. Do not aggregate away rare regulated slices. Do not reward module count growth. Do not treat user engagement as proof of mutualism.
Source reports used for this guide
These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.