Skip to main content
Every Worlds workflow starts with the same fundamental decisions. This guide walks you through those decisions to help you pick the right configuration.

Decision 1: What are you monitoring?

The first question determines your signal type.
You care about…Signal TypeExample
A specific object’s behavior — where it goes, how long it stays, how fast it movesTrack StateObstruction, wrong-way, speeding, loitering
What’s happening in a zone — how many objects are in it, regardless of which specific objectsZone StateCongestion, congregation, occupancy limits
How two objects interact — proximity, overlap, co-locationTrack State (batch)Near-miss, PPE compliance, tailgating

Decision 2: Do you need real-time alerting?

This determines your mode.
You need to react while conditions are developing. The workflow executes on every detection update.Trade-offs:
  • Higher processing volume (hundreds of executions per track)
  • Can alert while the event is still happening
  • Required for zone state monitoring
  • Must handle event closure separately (close path on the orchestrator)
Available signal types: Track State, Zone State

Decision 3: Which check node?

Based on your signal type, choose the appropriate check node(s):

For Track State

Check TypeUse when…Requires
Type I — Track in ZoneYou need to check if a track is in a zone meeting threshold conditions (dwell time, intersection, velocity)Streaming or Batch
Type II — Zone SequenceYou need to check if a track visited zones in a specific orderStreaming or Batch
Type III — Track InteractionYou need to check if two tracks interacted (proximity, overlap)Batch only
These can be composed together — chain multiple check types and the Event Orchestrator evaluates them with AND or OR logic.

For Zone State

Check TypeUse when…
Zone Activity CheckYou need to check aggregate zone conditions (track count, per-track dwell time and intersection thresholds)

Decision 4: Event scope

The Event Orchestrator prevents duplicate events by scoping them to an entity:
ScopeUse when…Example
TrackOne event per tracked objectObstruction — each vehicle gets its own event
ZoneOne event per zoneCongestion — one event per zone regardless of which tracks are in it
DeviceOne event per cameraCamera-level alerting
SiteOne event per siteSite-wide incident tracking

Quick reference: common use cases

Use CaseModeSignal TypeCheckScopeGuide
Obstruction / loiteringBatchTrack StateType ITrackGuide
CongestionStreamingZone StateZone ActivityZoneGuide
Zone intrusionStreamingTrack StateType ITrackGuide
Wrong-way detectionStreamingTrack StateType IITrack
Speeding in zoneStreamingTrack StateType ITrack
Safety near-missBatchTrack StateType IIITrack
PPE complianceBatchTrack StateType IIITrack
CongregationStreamingZone StateZone ActivityZone
Checkpoint bypassStreamingTrack StateType I + IITrack

Workflow template

Every workflow follows the same core structure:
Trigger → Check(s) → Event Orchestrator → Action(s)

Minimal workflow

Trigger → Check → Orchestrator → Event Manager (create)

Standard workflow

Trigger → Check → Orchestrator ─┬─ Create: Image → Event Manager → (GIF → Email)
                                └─ Close: Event Manager (close)

Advanced workflow (with VLM)

Trigger → Check → Orchestrator ─┬─ Create: Closest Frame → Image → VLM → Merge → Metadata → Event Manager
                                └─ Close: Event Manager (close)
Start with the minimal pattern and add complexity only as your use case requires.