Engine 19.0.0rc597 · Reader 9.0.0rc656 · Development snapshot
Arrivals and closures count how many top-level objects first appear or close on each local day. Ghost Observatory publishes completed objects separately from objects closed as cancelled or merged. These counts let you compare incoming work with the objects leaving the observed process.
What each daily count means
An arrival uses the object's admitted first observation. For an object supplied only through its record, with no process events, it can instead use a uniquely declared creation instant. If an event export starts after the object was created, the first observation can be later than its actual creation. A closure uses the outcome and closing day the Engine establishes from the admitted evidence.
Ad = Σi 1(opened_dayi = d)
Cd = Σi 1(outcomei = completed and closed_dayi = d)
Od = Σi 1(outcomei is cancelled or merged and closed_dayi = d)
opened_day in the selected scope. The indicator 1(condition) contributes one when the condition is true and zero otherwise. A, C and O are counts of objects on day d.The stored fields are flow_days.opened_count, completed_count and other_closed_count. They are daily counts; the Engine does not turn them into an hourly throughput rate. An object that arrives and completes on the same day contributes to both that day's arrivals and completions.
A two-day example
Consider four objects in a UTC analysis. A and B first appear on 1 January; A completes that day and B stays open. C and D first appear on 2 January; C is cancelled that day, while D's outcome is unknown. The table applies the daily count definitions to these four example objects.
| Day | New | Completed | Cancelled or merged | Not closed at day end |
|---|---|---|---|---|
| 1 January | 2 | 1 | 0 | 1 |
| 2 January | 2 | 0 | 1 | 2 |
Across the two days, four objects arrive, one completes and one is cancelled. The remaining stock is two: B and D. D remains in the daily not-closed count because there is no known closing outcome. The work-in-progress page explains why this daily stock has a different population from time-weighted average WIP.
Population, dates and missing days
The object counts require objects.hierarchy_status = root and a known opened_day. Child objects and unresolved parent relationships do not enter these top-level totals. Without that date, an object cannot be placed in the daily flow. A record-only object with an admitted creation date can qualify even though it has no process events.
The Engine derives opened_day and closed_day in run.timezone. The UTC timestamps and the local-day labels therefore serve different purposes. The selected scope also determines which histories are admitted. A bounded window cannot recover an object's earlier history merely by selecting its later records.
A stored flow row exists when there is an arrival, closure or process event. For a day between recorded days with no row, Reader fills the calendar with zero movements and carries the previous stock forward. There is no minimum sample size for these counts. Missing dates or excluded histories concern the population, not a statistical confidence threshold.
Where Reader shows the counts
Open Overview → Flow, route #overview/flow. Reader draws the published daily counts and adds them for its period totals only when all days are displayed. A truncated chart identifies the displayed subset and omits those whole-period sums.
Overview → Events per day, #overview/calendar, uses flow_days.events. That field counts process events on objects at any hierarchy level. An object can have several events in a day, so event counts and object arrivals answer different questions.
Published results
The definitions above describe the published flow_days, objects and windows results in the stated development snapshot.