The composable approach
Worlds provides check nodes that can be combined to express any detection use case. Which check nodes are available depends on the signal type from your trigger:
| Signal Type | Check Nodes | Question |
|---|
| Track State | Type I, Type II, Type III | What is this specific track doing? |
| Zone State | Zone Activity Check | What is happening in this zone? |
Rather than building specialized nodes for each use case, you compose these check types — and optionally add external checks like VLM — to express your business logic.
Track state compositions
Each track 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 combined checks object and evaluates all results using AND or OR logic to decide whether to create, update, or close an event.
Type I alone — track in zone
The simplest and most common pattern. A single Type I check handles use cases like:
- Obstruction/loitering (dwell + velocity thresholds)
- Zone intrusion (intersection threshold)
- Speeding in zone (velocity threshold)
Trigger → Type I → Event Orchestrator → Event Manager
Type I + Type II — zone sequence with thresholds
Combine zone presence conditions with directional/sequence validation:
- Wrong-way detection with speed check (was the vehicle going fast in the wrong direction?)
- Checkpoint compliance (did the vehicle stop at checkpoint A before entering zone B?)
Trigger → Type I → Type II → Event Orchestrator → Event Manager
Type I + Type III — proximity in zone
Combine zone-based conditions with track-to-track interaction:
- Person near forklift in a specific zone
- Two vehicles overlapping in a loading bay
Trigger (batch) → Type I → Type III → Event Orchestrator → Event Manager
Type III requires batch mode because interaction data is only available after tracks expire.
All three types
For complex safety rules:
- Person entered restricted zone (Type I), bypassed the checkpoint (Type II), and was near equipment (Type III)
Trigger (batch) → Type I → Type II → Type III → Event Orchestrator → Event Manager
Zone state checks
For zone state workflows, the Zone Activity Check evaluates zone-level conditions. It writes results to checks.zoneActivity:
Trigger (zone state) → Zone Activity Check → Event Orchestrator → Event Manager
This is used for congestion, congregation, and occupancy monitoring where you care about the aggregate number of tracks in a zone rather than any specific track.
Adding VLM (Vision Language Model) checks
For workflows that capture images, you can add a VLM check as an additional confirmation layer. This uses n8n’s built-in LLM nodes rather than a Worlds custom node:
Trigger → Check → Orchestrator → Capture Image → VLM Chain → IF (boolean) → Event Manager
The VLM analyzes the captured image and returns structured output (e.g., { "confirmed": true, "confidence": 0.92, "context": "..." }). You can use this two ways:
- As a check gate — feed the VLM boolean into an n8n IF node to conditionally create events. This adds AI confirmation to reduce false positives.
- As context metadata — always create the event but attach the VLM description and confidence as event metadata for human review.
See the Streaming Zone State Workflow for a complete VLM integration example.
Output accumulation
As data flows through multiple check nodes, the checks object accumulates:
{
"track_state": { ... },
"checks": {
"type1": {
"passed": true,
"matching_zones": ["79"],
"zone_details": { ... }
},
"type2": {
"passed": true,
"matching_zones": ["zone_b"],
"track_sequence": ["zone_a", "zone_c", "zone_b"],
"sequences": [ ... ]
}
}
}
The Event Orchestrator evaluates all checks entries:
- AND mode — all checks must pass for conditions to be met
- OR mode — any check passing is sufficient
Logic within vs. across checks
Understanding the logic layers:
| Level | Logic | Description |
|---|
| Within a zone | AND | All enabled thresholds must pass for a zone to match |
| Across zones | OR | At least one zone must match for the check to pass |
| Across check types | AND or OR | Configured on the Event Orchestrator |
Start with a single check type for most use cases. Add Type II or Type III only when your use case genuinely requires sequence or interaction detection. Simpler workflows are easier to debug and maintain.
Common compositions reference
| Use Case | Signal Type | Mode | Checks | Description |
|---|
| Obstruction / loitering | Track State | Batch or Streaming | Type I | Dwell time + low velocity in zone |
| Wrong-way detection | Track State | Streaming | Type II | Zone sequence in forbidden order |
| Safety near-miss | Track State | Batch | Type III | Person/vehicle proximity |
| PPE compliance | Track State | Batch | Type III | Person/PPE bbox overlap |
| Congestion | Zone State | Streaming | Zone Activity | Track count threshold in zone |
| Congregation | Zone State | Streaming | Zone Activity | People gathering in area |
| Speeding in zone | Track State | Streaming | Type I | High velocity in zone |
| Unauthorized entry | Track State | Streaming | Type I + II | Zone presence + bypassed checkpoint |
| Person-vehicle in zone | Track State | Batch | Type I + III | Zone presence + interaction |
| VLM-confirmed congestion | Zone State | Streaming | Zone Activity + VLM | Zone check + image confirmation |