CA-04
Pre-Release Stage Thickening
CFD Advanced
Default severity: medium
PrioritizationProcessMetricsOutputRisk
What it detects
The configured pre-release stages are growing thicker over time — a release pipeline constraint is accumulating completed work downstream of all team activity.
Detection formula
pre_release_stages = config.workflow.pre_release_stages // e.g. \[\'Ready for Release\', \'Deploying\'\] FOR each_stage S IN pre_release_stages: IF trend(band_height(S), config.ca.thickening_window_days) = \'up\' // default: 30d AND band_height(S, today) > band_height(S, today - config.ca.thickening_window_days) * config.ca.thickening_threshold // default: 1.2x THEN FLAG pipeline_blockage at S Correlate with PL-01, PL-02Examples in practice
- A team shows the configured pre-release stages are growing thicker over time while pre release stages is set to Configured per workspace.
- Example signal: The configured pre-release stages are growing thicker over time — a release pipeline constraint is accumulating completed work downstream of all team activity.
Suggested response
Use planning-event context when interpreting advanced CFD bottlenecks, spikes, and ageing WIP.
Coaching playbook
Symptom
The configured pre-release stages are growing thicker over time — a release pipeline constraint is accumulating completed work downstream of all team activity.
Why it matters
When "Pre-Release Stage Thickening" 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
Use planning-event context when interpreting advanced CFD bottlenecks, spikes, and ageing WIP.
Facilitation questions
- What system change would stop "Pre-Release Stage Thickening" 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.