CC-05
Rolling Avg Dip — Real vs False Improvement
Control Chart
Default severity: medium
ProcessMetricsOutputRisk
What it detects
Rolling average dropped below the configured dip threshold — requires validation over the configured window to classify as genuine improvement or false signal.
Detection formula
IF rolling_avg \< overall_avg * config.cc.dip_threshold // default: 0.7 THEN WATCH After config.cc.dip_validation_days // default: 30d: IF recovered > overall_avg * config.cc.dip_recovery_threshold // default: 0.85 THEN RECLASSIFY as OL-04 (false improvement)Examples in practice
- Rolling averages, control limits, or band width diverge from expected statistical bounds.
- Recent control-chart windows show drift, clusters, or missing limit configuration.
- A team shows rolling average dropped below the configured dip threshold while dip threshold is set to 0.7.
Suggested response
Treat the metric as a control signal: confirm limits, windows, and cross-team spread before acting.
Coaching playbook
Symptom
Rolling average dropped below the configured dip threshold — requires validation over the configured window to classify as genuine improvement or false signal.
Why it matters
When "Rolling Avg Dip — Real vs False Improvement" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.
What you can achieve
Treat the metric as a control signal: confirm limits, windows, and cross-team spread before acting.
Facilitation questions
- What system change would stop "Rolling Avg Dip — Real vs False Improvement" from firing again?
- What do the cited issues have in common — same root cause or same workaround?
- Who owns the two-week experiment and how will we verify on the next import?
Run this rule against your own tracker data with Flow Analyzer.