MI-09
Status Reversal Clock Reset
Metric Integrity
Default severity: medium
MetricsQualityRisk
What it detects
An issue transitioned from a Done status back to an active status and then to Done again — the reported cycle time is shorter than the true elapsed time.
Detection formula
IF pattern MATCHES (done_status -> active_status -> done_status) in changelog THEN FLAG true_cycle_time = final_done_date - original_active_date (first ever IN_PROGRESS) IF true_cycle_time > reported_cycle_time * config.mi.clock_reset_ratio_threshold // default: 1.5x THEN CRITICALExamples in practice
- Done -\> In Progress -\> Done — second cycle time appears clean
- Bulk admin transitions or resolution anomalies distort cycle time and velocity metrics.
- Closure timestamps or fields suggest data repair rather than organic delivery.
Suggested response
Audit closure and field patterns so metrics reflect real completion, not bulk admin updates.
Coaching playbook
Symptom
An issue transitioned from a Done status back to an active status and then to Done again — the reported cycle time is shorter than the true elapsed time.
Why it matters
When "Status Reversal Clock Reset" 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
Audit closure and field patterns so metrics reflect real completion, not bulk admin updates.
Facilitation questions
- What system change would stop "Status Reversal Clock Reset" 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.