Engine 19.0.0rc597 · Reader 9.0.0rc656 · Development snapshot
A repeated activity occurs more than once in the same object's recorded history. Ghost Observatory counts the occurrences after the first, the objects containing those repeats and a narrower pattern called a repeat after return. These measures describe recorded sequences; establishing why an activity repeated requires the underlying evidence.
Counting repeated activities
For activity a, let nia be its occurrence count in object i. Let D contain the scope's objects whose process steps all have a decided order.
Ra = Σi ∈ D max(nia − 1, 0)
Ha = Σi ∈ D 1(nia ≥ 2)
The corresponding fields are activity_rework.repeat_event_count and activity_rework.objects_with_repeat. The separate object_count includes every scope object containing that activity, including objects whose order is unknown. Its population is therefore broader.
A repeat, a direct repeat and a return
Take an ordered object T with the sequence A → B → A → B → B → C. A occurs twice, B three times and C once. A second object U contains two B events whose order is undecided. The table applies the counting rules above to these two objects.
| Activity | Repeat events | Objects with repeats | Objects with activity | Repeats after return |
|---|---|---|---|---|
| A | 1 | 1 | 1 | 0 |
| B | 2 | 1 | 2 | 1 |
| C | 0 | 0 | 1 | 0 |
For T, B's second and third occurrences are repeats. The third B directly follows another B: a self-loop in the process map.
repeat_after_return_count has a more specific rule. A repeat contributes when the immediately preceding step has a different activity, and that preceding activity first appeared before the repeated activity. At position four, B follows A; A first appeared before B, so that B contributes one. At position five, B follows B and adds no return count. The count is attached to the activity repeated after the return. It uses first appearances in the recorded sequence, rather than a configured reference order.
Unknown order and window boundaries
U contributes to B's object_count but contributes no repeat events or objects-with-repeat count. Reading 1 ÷ 2 as a complete estimate of repeat prevalence would ignore U's unavailable order. If every relevant object's order is undecided, the repeat counts can be zero even though the evidence cannot establish an absence of repetition.
Activity rework uses the recorded histories of objects belonging to the scope. In a bounded window, this can include their events outside the window's event subset. It should not be described as repetitions occurring only between the selected dates. There is no minimum-sample threshold for these counts. The return count is NULL when the run publishes no object transitions.
The separate object-level count
objects.repeated_step_count counts repeats within an activity and its routing operation, when the operation is declared. A repeated activity at a different operation can therefore differ from the activity-wide count. Its formula is the sum of max(count − 1, 0) over those activity-and-operation groups in one object. Incomplete histories or an object extending outside the window can withhold this whole-object value.
Where Reader shows the counts
The single-type Processes → Map view, #processes/map, uses activity counts for its rework chips. These are scope-wide activity figures: the map's object-type control does not recalculate them for a type. Objects → Object detail, #objects/object, presents the separate object-level measure.
A repeat may represent correction, repeated approval, retries or a legitimate recurring step. The count alone does not distinguish those explanations or establish a quality failure.
Published results
The published results are activity_rework and objects.repeated_step_count. Use the counting rules above when interpreting their totals.