Skip to main content

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 TypeCheck NodesQuestion
Track StateType I, Type II, Type IIIWhat is this specific track doing?
Zone StateZone Activity CheckWhat 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:
  1. 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.
  2. 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:
LevelLogicDescription
Within a zoneANDAll enabled thresholds must pass for a zone to match
Across zonesORAt least one zone must match for the check to pass
Across check typesAND or ORConfigured 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 CaseSignal TypeModeChecksDescription
Obstruction / loiteringTrack StateBatch or StreamingType IDwell time + low velocity in zone
Wrong-way detectionTrack StateStreamingType IIZone sequence in forbidden order
Safety near-missTrack StateBatchType IIIPerson/vehicle proximity
PPE complianceTrack StateBatchType IIIPerson/PPE bbox overlap
CongestionZone StateStreamingZone ActivityTrack count threshold in zone
CongregationZone StateStreamingZone ActivityPeople gathering in area
Speeding in zoneTrack StateStreamingType IHigh velocity in zone
Unauthorized entryTrack StateStreamingType I + IIZone presence + bypassed checkpoint
Person-vehicle in zoneTrack StateBatchType I + IIIZone presence + interaction
VLM-confirmed congestionZone StateStreamingZone Activity + VLMZone check + image confirmation