Condition-triggered recording is simple to describe: when this signal exceeds that value, record a window with some pre-roll. The first implementation evaluated the condition on the central server against the ingested stream. It worked, and it was wrong in three ways that only show up in production.
Three ways a central trigger fails
- Latency. Any ingest lag means the decision arrives after the transient. A short spike should be enough to fire a trigger; evaluated centrally, it can arrive too late.
- Timestamps. A decision made on arrival time is a decision on the network's clock. Two machines' windows cannot be compared if each window's edges depend on how loaded the uplink was.
- Availability. A trigger that lives in a browser tab or a backend process stops when either restarts. Operators do not re-arm triggers after a deploy at three in the morning.
The edge design
An armed trigger is pushed to the EdgeBox as configuration. The trigger engine — comparison operators, ALL/ANY combination, pre-roll, post-roll, cooldown and maximum duration — evaluates it against the local raw data, using the timestamps the acquisition stamped on the data itself. Fire and clear events carry those timestamps upstream, and pre-roll comes from recent data held on the box.
The trigger's open/closed state is also available as an ordinary signal, so a downstream computation, including an AI pipeline's gate, can bind to it like any other input.
What changed
A burst of trigger windows on a grinding cycle fired and cleared at edge timestamps with zero gaps, with no browser open and straight through a server redeploy. Windows are now cut on the data's clock, and a window is only closed once all of its data has arrived.
