What are signals?
A signal is an event emitted by the state machine when something changes about a track, a zone, or an activity chronicle. Every item that arrives at your workflow’s trigger node includes asignal field indicating what happened.
There are three families of signals depending on your trigger configuration:
- Track state signals —
track_created,track_updated,track_expired(Detection Webhook Trigger) - Zone state signals —
zone_occupied,zone_updated,zone_empty(Detection Webhook Trigger) - Activity chronicle signals —
chronicle_created,chronicle_updated,chronicle_closed(Activity Chronicle Trigger)
Track state signals
Track state signals fire for individual track lifecycle events. There are three types:track_created
Fired once when a new track is first detected. This is the first time the state machine has seen this object. At this point the track state is minimal — there’s only one detection, so velocity is zero, dwell time is zero, and zone data may be sparse. Common use: Most workflows do not act ontrack_created because there isn’t enough data to make meaningful decisions yet.
track_updated
Fired on every subsequent detection after the track is created. This is by far the most common signal — a track that lasts 5 minutes at 1 detection/second generates ~300track_updated signals.
Each update includes the fully enriched track state with current velocity, dwell times, zone intersections, and more. The data gets richer over time as more detections accumulate.
Common use: This is where most business logic runs. Your checks evaluate the current state on each update and the Event Orchestrator decides whether conditions warrant creating or closing an event.
track_expired
Fired once when the state machine hasn’t received a detection for this track within the TTL window (default: 15 seconds). The track is considered gone. The expired signal includes the final track state — the last known position, total dwell times, complete zone history, and final velocity measurements. Common use: Used for “track summary” workflows that only care about the complete lifecycle. Also used by the Event Orchestrator to close events when a track disappears. Batch processing workflows typically emit data only on track expiration.Signal flow example
Filtering signals in your workflow
The Detection Webhook Trigger delivers all three signal types by default. You can use the signal type in your workflow logic — for example, the Event Orchestrator usestrack_expired to know when to close events.
If you only want to process certain signals, you can add an IF node after the trigger to filter:
Most workflows process all signals and let the check nodes and Event Orchestrator handle the logic. You typically don’t need to manually filter signals.
Zone state signals
Zone state signals fire when the occupancy of a monitored zone changes. They are available only in streaming mode with the signal type set to Zone State.zone_occupied
Fired once when the first track enters a previously empty zone. The zone transitions from 0 to 1+ active tracks. Common use: Triggers the start of zone monitoring. The Zone Activity Check may not pass yet if only one track is present.zone_updated
Fired on every change to the zone’s active track list — a track enters, a track exits, or an existing track’s state updates (new detection, changed position). This is the most common zone signal. A busy zone can generate manyzone_updated signals as tracks move in and out.
Common use: This is where zone-level business logic runs. The Zone Activity Check evaluates the current track count and thresholds on each update.
zone_updated frequency depends on the subscription’s zone emit mode. In the default all mode (shown above), it fires on every detection in the zone. In composition mode, it fires only when the zone’s filtered tag → count composition changes, plus a periodic heartbeat — useful for avoiding overlapping executions on busy zones. See Composition emit mode in the State Machine Overview.zone_empty
Fired once when the last track leaves the zone. The zone transitions back to 0 active tracks. Common use: Used by the Event Orchestrator to close zone-scoped events when the zone clears.Zone signal flow example
Zone state payload
Each zone signal includes the full list of active tracks in the zone:Activity chronicle signals
Activity chronicle signals fire for the lifecycle of activity chronicles — externally-produced event summaries on the Worlds platform, as opposed to track and zone signals which are derived from raw detections. They are delivered by the Activity Chronicle Trigger and are available only in streaming mode; there is no batch equivalent.chronicle_created
Fired once — the first time the state machine sees this chronicle ID, while the chronicle is still open (endTime is null).
Common use: Start tracking a chronicle for the duration of its lifecycle.
chronicle_updated
Fired on any other content change to a chronicle the state machine already knows about, including edits made after the chronicle has closed. Common use: React to changes in chronicle details — status, priority, labels — while the chronicle is open or after it has closed.chronicle_closed
Fired once when the chronicle’sendTime transitions from null to set. If the state machine sees a chronicle for the first time and it is already closed, chronicle_closed fires immediately with no preceding chronicle_created.
Common use: Finalize processing for a chronicle — for example, generating a summary or notification once the underlying event has concluded.
Dedup guarantee: the state machine emits exactly one
chronicle_created per chronicle ID. Deduplication is content-based — the state machine stores a hash of the chronicle’s raw JSON per chronicle ID and suppresses byte-identical re-deliveries. This lifecycle state survives state machine restarts.