Why Events Matter
Intervals tell you what happened at a time. Events tell you what was happening — and that is what makes numbers explainable.
Measures answer "what was the value during this period". That is enough for a great deal of reporting, and it runs out at exactly the point where reporting becomes useful.
An event scheme answers a different question: what was happening.
The gap intervals leave#
Consider a bottling line with hourly production figures. The 14:00 hour produced 4,100 units and the 15:00 hour produced 1,850.
The measures are correct and completely unhelpful. Was there a changeover? A breakdown? A different product with a slower rate? A planned cleaning cycle? A shift handover? The hourly number cannot say, and neither can any aggregation built from it.
Now suppose the same period carries events:
13:20 – 14:48 Production Run Product: Orange 1L Operator: J. Mokoena
14:48 – 15:06 Stoppage Reason: Label jam Category: Unplanned
15:06 – 15:31 Changeover From: Orange 1L To: Apple 500ml
15:31 – ... Production Run Product: Apple 500ml Operator: J. Mokoena
The same two numbers are now explainable, and far more importantly they are now analysable: rate per product, downtime by reason, changeover duration, output per operator. None of that is reachable from interval data alone.
What an event is#
An event has a start, usually an end, and attributes describing it.
That shape is deliberately different from an interval:
| Interval | Event | |
|---|---|---|
| Duration | Fixed by the calendar | Whatever actually happened |
| Coverage | Tiles the timeline with no gaps | Gaps and overlaps are normal |
| Boundaries | Known in advance | Discovered from the data |
| Identity | The period is the identity | Each event is its own thing |
| Attributes | A value | Any number of named attributes |
The consequence worth internalising: anything with a start, an end, and attributes is an event, not a measure and not a calendar. Trying to express a production run as a time scheme, or a batch as a measure, produces something nobody can maintain.
What events are used for#
Downtime and Pareto analysis. Stoppages with a reason attribute give you the ranked "what costs us the most time" chart that drives improvement work. This is the most common use and often the first one built.
Batch and campaign tracking. A batch carries its recipe, its raw material lot, its operator, its quality results. Genealogy and traceability follow from that.
Product-based analysis. Rate, yield, and consumption per product, rather than blended across everything the line made.
Equipment utilisation. Running, idle, and fault states as events give availability that sums correctly.
Shift and crew accountability. A shift event carrying a crew attribute lets you compare crews without encoding a roster into the calendar.
Cleaning and maintenance cycles. CIP cycles with media, duration, and temperature attributes, so you can show they completed properly.
Events feed measures#
Events are not a separate reporting silo. They come back onto the interval grid through event-aggregated measures, which is what makes them usable in ordinary charts, limits, and consumers.
An event-aggregated measure asks one question of an event scheme, per interval:
- How many production runs started today?
- How many minutes was the line down this shift?
- How long did the average changeover take this week?
- How long since the last quality failure?
The anchor is which question you are asking, and there are fourteen of them. The one to know first is Active Duration, because it is the only duration anchor whose values across an interval sum to the interval length — which is what makes availability and utilisation percentages meaningful. See Event Anchor and Trigger Reference.
The event or the interval?#
A useful test when you are unsure which to model.
Model it as an event when it has a start and an end that are decided by the plant, when you want to describe it with attributes, when instances need to be counted or compared, or when gaps and overlaps are normal.
Model it as a measure when you want a value per fixed period.
Model it as a time scheme when the periods tile the timeline continuously on a rule — hours, days, shifts, financial months.
Examples that are frequently modelled wrongly:
| Thing | Correct model | Often wrongly modelled as |
|---|---|---|
| Production run | Event | A calendar period |
| Batch | Event | A measure |
| Stoppage | Event | A measure that is 1 when stopped |
| Rotating crew roster | Event attribute on a shift event | A time scheme |
| Public holiday | Event, or a manual target of zero | A calendar exception |
| Campaign | Event | A manual time scheme |
| Shift | Shift scheme on a time scheme | An event |
That last row is the exception worth noting: shifts do tile the timeline on a rule, so they belong to the calendar. Which crew worked the shift does not, so that is an attribute.
The cost of events#
Events are not free, and it is fair to know what you are taking on.
They require triggers that reliably detect starts and ends, and getting triggers right against real plant data is the substantial part of the work. A trigger that misses an end leaves an event open indefinitely; one that fires twice produces duplicates.
They require attributes to be populated, whether read from a source or entered by a person. An event scheme with an unfilled reason attribute produces a Pareto chart with one enormous "unspecified" bar.
They require thought about retention. Events accumulate, and the scheme has archive and purge settings that need deciding rather than defaulting.
None of this is a reason to avoid them. It is a reason to build one event scheme properly and get value from it, rather than six half-configured ones.
Where to start#
If you are new to events, build a downtime scheme on one machine:
- One trigger pair on a state tag: the event starts when the machine stops and ends when it runs again.
- One enumerated attribute: the reason, chosen from a list.
- One event-aggregated measure: downtime minutes per shift, using Active Duration.
- One Pareto chart of downtime by reason.
That is a complete, genuinely useful analysis, and it exercises every concept you need for anything more ambitious.
Then read Designing an Event Scheme.