Engine 19.0.0rc597 · Reader 9.0.0rc656 · Development snapshot
What does processing time measure?
Processing time is the duration attributed to a recorded process step. Ghost Observatory uses the source's stated duration, or a start-to-end duration when that source's duration policy permits it. The published event field is events.processing_time_sec.
The source determines what the recorded step represents. A ten-minute system activity does not, by itself, establish ten minutes of a person's effort. Person work records have a separate work-time calculation.
Pobject = ∑ pi
Parallel durations add up
A complete object history contains these three activities. Their stated processing durations agree with their clock spans.
| Activity | Clock interval | Duration |
|---|---|---|
| A | 09:00–09:10 | 10 minutes |
| B | 09:02–09:08 | 6 minutes |
| Close | 09:12–09:14 | 2 minutes |
The Engine publishes objects.total_processing_time_sec = 1080: 18 minutes. The object's lead time is 840 seconds, or 14 minutes. The elapsed interval and the sum of activity durations use different clocks.
The total is a sum of activity durations. It does not merge overlapping activity intervals into one clock. This distinction matters when work runs in parallel: a processing total larger than lead time can be consistent with the evidence.
Which events enter the total?
Use events with is_process_step = 1 when inspecting process durations. Desktop screen intervals can also carry a value in processing_time_sec, but have is_process_step = 0 and do not become process steps.
Activities listed in EXTERNAL_WAIT_ACTIVITY_TOKENS have their time classified as waiting. Their processing value is empty and contributes zero to the object's processing sum when the external-wait duration is known. The waiting article explains where that time appears.
Processing time, system-recorded work, self-reported work and unclassified work remain separate evidence classes in duration_stats. Adding their summary rows would mix different measurements and can count the same clock time several times.
Missing durations and analysis windows
The object total requires complete declared history and a known duration for every relevant step. An unknown ordinary processing duration makes the total NULL. An unknown external-wait duration also prevents the Engine from certifying the complete total. Incomplete history and a partly outside-window object withhold the whole-object figure.
Activity-duration summaries handle a bounded window separately. A step crossing a window boundary is excluded from that window's duration population; the Engine does not pretend its entire duration occurred inside the window. The unbounded scope can measure the step whole. The diagnostic window_steps_cross_edge records this exclusion.
A known zero duration is a value. An absent duration is not. This difference affects counts, quantiles and which observations can enter a positive-duration density curve.
How the Reader uses processing time
The Timing workspace reads published duration_stats and can retrieve the process events behind an activity's timing points. The Engine calculates the summaries; filtering a displayed page does not recalculate them. The ordinary median and P90 require five and twenty known values respectively.
Use percentiles to describe the middle and tail, KDE to inspect the duration distribution, and SPC for the published control-chart calculation. None of these changes the underlying meaning of a source duration.
Processing time is not automatically labour time
A recorded activity can include machine execution, a system operation or a span during which a step remains active. Whether that interval represents continuous work depends on the source. It cannot be converted into a person's working time simply because an assignee appears on the row.
For labour-time questions, inspect the separate work-interval calculation and its evidence class. For the elapsed life of an order or claim, use lead time. Choosing the correct clock comes before comparing people or processes.