Skip to main content
The Worlds check nodes evaluate detection data against configurable conditions. They are the business logic layer between your trigger node and the Event Orchestrator — taking raw detection data and determining whether it matches the criteria for your use case. Which check node you use depends on the signal type from your trigger node:
Signal TypeCheck NodeQuestion it answers
Track StateTrack Checks (Type I, II, III)“What is this specific track doing?”
Zone StateZone Activity Check”What is happening in this zone?”

​
Track Checks

The Track Checks node provides three check types that can be composed together. Each type examines a different aspect of track behavior.

Type I

Track in ZoneIs a track in a zone meeting threshold conditions?

Type II

Zone SequenceDid a track visit zones in a specific order?

Type III

Track InteractionDid two tracks interact with each other?

​
Zone Activity Check

Zone Activity

Zone Activity CheckAre enough tracks in a zone meeting threshold conditions? Used for congestion, congregation, and occupancy monitoring.

​
Composing use cases

Most real-world detection use cases map to one or more check types:
Use CaseSignal TypeCheck TypesDescription
Obstruction / loiteringTrack StateType ITrack in zone with high dwell time, low velocity
Wrong-way detectionTrack StateType IITrack visits zones in forbidden order
Safety near-missTrack State (batch)Type IIIPerson track interacts with vehicle track
PPE complianceTrack State (batch)Type IIIPerson bbox overlapping with PPE detection
CongestionZone StateZone ActivityMultiple vehicles in an aisle zone
CongregationZone StateZone ActivityMultiple people gathering in an area
Unauthorized zone entryTrack StateType I + IITrack enters restricted zone after bypassing checkpoint
Person-vehicle proximity in zoneTrack State (batch)Type I + IIITrack in specific zone AND interacting with another track type

​
How checks compose

Each check type writes its results to a separate namespace (checks.type1, checks.type2, checks.type3) and preserves all input data. This means you can chain them in sequence: 
Trigger → Type I Check → Type II Check → Event Orchestrator
The Event Orchestrator reads the checks object and evaluates all results together using AND or OR logic.

​
Common output structure

All three types share the same output pattern: 
{
  "track_state": { ... },
  "checks": {
    "type1": {
      "passed": true,
      "matching_zones": ["42", "79"],
      "matching_zone_count": 2,
      "zone_details": { ... }
    }
  }
}
FieldDescription
passedWhether the check conditions were met
matching_zones / matching_interactionsWhich zones or tracks matched
zone_details / interaction_detailsDetailed per-zone or per-interaction results with threshold breakdowns
reasonIf passed is false, explains why (e.g., no_zones_met_all_thresholds)

​
Auto check target

All check types automatically detect whether to check active zones (for streaming/live data) or historical zones (for batch/expired tracks) based on the trigger mode. You can override this in advanced settings.