Check Types Overview

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 Type	Check Node	Question it answers
Track State	Track Checks (Type I, II, III)	“What is this specific track doing?”
Zone State	Zone 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 Case	Signal Type	Check Types	Description
Obstruction / loitering	Track State	Type I	Track in zone with high dwell time, low velocity
Wrong-way detection	Track State	Type II	Track visits zones in forbidden order
Safety near-miss	Track State (batch)	Type III	Person track interacts with vehicle track
PPE compliance	Track State (batch)	Type III	Person bbox overlapping with PPE detection
Congestion	Zone State	Zone Activity	Multiple vehicles in an aisle zone
Congregation	Zone State	Zone Activity	Multiple people gathering in an area
Unauthorized zone entry	Track State	Type I + II	Track enters restricted zone after bypassing checkpoint
Person-vehicle proximity in zone	Track State (batch)	Type I + III	Track 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": { ... }
    }
  }
}

Field	Description
`passed`	Whether the check conditions were met
`matching_zones` / `matching_interactions`	Which zones or tracks matched
`zone_details` / `interaction_details`	Detailed per-zone or per-interaction results with threshold breakdowns
`reason`	If `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.

Trigger Nodes

Check Nodes

Event Nodes

Action Nodes

Track Checks

Type I

Type II

Type III

Zone Activity Check

Zone Activity

Composing use cases

How checks compose

Common output structure

Auto check target

​Track Checks

Type I

Type II

Type III

​Zone Activity Check

Zone Activity

​Composing use cases

​How checks compose

​Common output structure

​Auto check target

Track Checks

Zone Activity Check

Composing use cases

How checks compose

Common output structure

Auto check target