Solution Design Status Report

“Signed off” alone invites a reader to count internal or cyber approval and conclude the programme is further ahead than it is. The rework bar sits between the outer pair because that is where much of the distance goes.

A circle is how many designs sit at that stage right now; the weight of a line is how many have travelled it since the programme began, which is a total and not a rate. A red underline marks a gate whose average dwell is past its SLA. A path animates only while it carries work, so a rework loop nothing has entered is drawn still rather than dropped -- an empty stage is a finding. Rework returns to Solution Design because that is where the design is reworked; Jira records the ticket bouncing back to the gate, since rework is a computed span rather than a status. Every figure behind the diagram is in the stage table below, which prints.

Weekly figures come from Jira transition dates. Many of this programme's transitions were recorded in batches after the event, so a week reflects when work was logged as much as when it moved.

Avg days from entering a stage to the next, counting both the SDs that completed the transition and those still waiting in it (hover a figure for the split). SLA = target where defined; red avg is over SLA. batch-clicked stages were advanced through several statuses in one retroactive Jira update, so their ~0-day gaps are an artifact. Open is measured from the date the SD was raised, so it counts the wait before anyone picked the ticket up; the per-SD timeline starts at first work instead, which is why most SDs draw no Open band there. This pull carved 323 SD-days of in-gate rework out of whichever review gate was running at the time, and a further 192 raised after Complete — read against a report from before that split, these gates will look faster, not because the gate changed but because that time is now attributed to rework. Each rework row is named for the review that RAISED the finding, not for the gate the days came out of: cyber rework is Rework 2 wherever its clock ran, including past Complete. Each pair describes time INSIDE the gate row beneath it, so they overlap it rather than dividing it: the gate figure is still the full dwell, which is what the SLA column is measured against. A rework row showing — is unoccupied rather than unmeasured: no finding in this pull put time into that stage. Rework 1 waits on a finding raised at Internal Review, and no review raises one there. ARB Review → ARB Rework measures the gap to ARB's feedback being WRITTEN DOWN, not to the board's verdict: feedback is raised as a sub-task days or weeks after the review that produced it — one ticket's description names an ARB held on 12 Jul against a ticket created on 6 Aug — so this row carries the delay in recording the feedback as well as the wait for it. Cyber Review's figure here is the gate's full dwell and cannot see how long cyber itself took: a finding raised after its design had already left the gate does not register in this row at all. The cyber rework section below measures that separately.

Cycle time is computed here as first work start (transition out of Open) to Complete, from the two transition dates rather than Jira’s own cycle-time field, so every day count on this page comes from one clock. 6 of 18 completed SDs share one Complete date (29 Jul 2026), so those timestamps reflect a batch or administrative close rather than independent completion events; cycle times ending on that date should be read with that caveat. Headline Avg/Median use the 18 completed feature SDs (Platform enablers excluded). Across all 18 completed SDs incl. same-day Platform items: avg 27.3d, median 32.5d.

The amber and red age bands apply to every queue equally. The per-gate SLAs are the commitments each gate made. A queue can be red on the first and inside the second, and both statements are true, so the SLA flag is shown separately rather than folded into the colour.

A design counts in a week if it was sitting at that stage during it, not if it arrived during it. Arrivals were measured first and describe the wrong event: 41% of stage segments in this export last zero days, because gates get clicked through in batches, so an arrivals grid spikes on the day somebody did admin. Every figure links to its own designs in Jira by key, because a query written against the gate NAME returns nothing — these statuses were renamed, and Jira matches the name recorded at the time.

The stage table shows one figure per stage, combining work that moved on with work still waiting. This model splits those two apart again, because they behave differently. The moved-on component says what a stage costs when it is flowing (3.8d, 3.7d, 4.7d, 7.5d, 10.2d), summing to a clean path of about 30 days. The waiting component is backlog: 527 SD-days are currently sitting past SLA across the queue. Baseline = clean path + the whole backlog, calibrated so it lands on the 17 Oct 2026 run-rate forecast; clear every trapped day and hold both gates to SLA and it lands on the clean path at SLA, 25 days. Both ends of that range are numbers you can find elsewhere on this page rather than model output. Each action releases a defined set of trapped SD-days and, for the two gates, lowers that stage's dwell to its target; where actions overlap the larger release wins, so any combination can be read off and the order does not matter. An earlier version used mean queue age as the stage dwell, which reported a stage as averaging weeks on the strength of two stuck tickets and contradicted the table above.

Board feedback is raised as a sub-task days or weeks after the review that produced it: one ticket describes an ARB held on 12 Jul against a ticket created on 6 Aug. These ages carry the delay in writing the feedback down as well as the wait for it.