Engine 19.0.0rc597 · Reader 9.0.0rc656 · Development snapshot
Two WIP figures answer different questions
Work in progress (WIP) counts objects that have arrived but have not yet closed. Daily WIP is a running balance of top-level objects' first arrivals and final published closures. Average WIP measures how many eligible objects were open at the same time, weighted by the length of each interval. Ghost Observatory publishes both, with different rules for reopening and unknown outcomes.
The daily field is flow_days.not_closed_count_end. The time-weighted field is windows.average_wip. A mean of the daily values is not the Engine's average-WIP calculation.
Daily stock from arrivals and closures
WIPd = ∑k ≤ d (openedk − completedk − other_closedk)
On day one, two objects first appear and one completes: ending WIP is one. On day two, two more first appear and one is cancelled: ending WIP is two. If one remaining object's outcome is unknown, it still contributes to this not-closed count.
A temporary closure followed by reopening does not reduce this daily balance: only the object's final published closing day does. Average WIP removes those intervening closed stretches from its time calculation.
The population is top-level objects with a known opened_day. First appearance means the recorded start represented by that field, rather than an assumed creation date. Counts of process events on the same chart are a separate population and can include child objects.
Time-weighted average WIP
Average WIP = (∑ open seconds across eligible objects) / (b − a)
Consider a ten-second observation period.
| Object | Observed history | Open seconds |
|---|---|---|
| A | Starts at 0; closed from 3 to 5; reopened; finally closes at 10 | 8 |
| B | Starts at 2; still open at 10 | 8 |
| C | Starts at 4; cancelled at 8 | 4 |
The result is (8 + 8 + 4) / 10 = 2 objects. Individual intervals are clipped to the measured period. Cancellation and merging end open occupancy just as completion does.
Population and window boundaries
Average WIP needs a known lifecycle state, a usable temporal envelope and ranked events. Unknown-state objects are excluded with the diagnostic trace_followup_evidence_unavailable; the daily stock keeps them. Generated identities and unusable temporal evidence cannot establish an average-WIP trajectory.
Objects begun before a bounded window are excluded from its average-WIP and survival models because that window cuts their history. An object beginning inside the window and continuing beyond its end can contribute through the cutoff. The daily stock follows its separate requirement for a top-level object with a known opened_day. Use the unbounded scope to examine full histories.
The denominator begins at the first eligible arrival, even if the configured window begins earlier. The cutoff is the declared window end, or the latest admitted data instant when no end is declared. A zero-length period produces NULL. The survival model's minimum-object threshold does not itself suppress average WIP.
Reading flow in the Reader
Overview's flow view reads the published daily rows and average. A civil day with no stored movements carries forward the previous stock and adds zero movements or process events. Days follow run.timezone. The view also reports top-level objects whose start is undated or outcome unresolved.
Little's queuing formula relates long-run average stock, arrival rate and time in a system under its assumptions. This snapshot calculates occupancy from observed intervals; it does not publish a Little's-law duration estimate or a throughput-rate metric. Mixing its daily stock population with a completed-only median would not establish that relationship.
WIP, throughput and lead time
Work in progress is a stock: how much work is unfinished at a point in time. Throughput is a flow over a stated period. Lead time is a duration for an individual work object. A high WIP count alone cannot tell you whether arrivals increased or closures slowed.
Read arrivals and closures alongside the stock, then inspect object histories. Keep the unit explicit: orders, events and people are different counts. The daily and average WIP fields also have different eligibility rules, so a disagreement between them needs its population checked.