Type I: Track in Zone

Type I checks evaluate whether a track is present in specific zones and whether its zone interaction metrics (intersection, dwell time, velocity) meet configured thresholds.

When to use

Use Type I for any use case where the core question is “is this object in this zone doing this thing?”:

Obstruction / loitering — dwell time above threshold, velocity below threshold
Zone intrusion — any presence in a restricted zone with minimum intersection
Congestion — multiple tracks in a zone exceeding thresholds
Speeding — velocity above threshold in a zone
Stopped vehicle — velocity below threshold for extended dwell time

How it works

The node reads the track’s zone data (active zones for live data, historical zones for expired tracks)
For each zone that has a threshold configuration, it evaluates all enabled thresholds
A zone passes if all enabled thresholds pass (AND logic within a zone)
The overall check passes if at least one zone passes (OR logic across zones)

Configuration

Site

Select the Worlds site. This loads the available zones for threshold configuration.

Threshold groups

Threshold groups define which zones to check and what thresholds to apply. Each group contains:

Parameter	Description
Zone IDs	Which zones this group applies to
Intersection	Minimum overlap between the object’s bounding box and the zone polygon
Dwell Time	How long the object has been in the zone
Velocity	How fast the object is moving within the zone

Each threshold has:

Enable toggle — only enabled thresholds are evaluated
Operator — >=, >, <=, <, ==
Value — the threshold value

Threshold units:

Threshold	Unit	Description
Intersection	% (0–100)	Percentage of bounding box overlapping the zone
Dwell Time	seconds	Time spent in the zone
Velocity	px/s or m/s	Speed within the zone (pixel or geo-referenced)

You can create multiple threshold groups to apply different thresholds to different zones. A zone can only belong to one group.

Advanced settings

Parameter	Default	Description
Check Target	Auto	`auto` detects from trigger mode. Override with `active` or `history`.
Debug Mode	false	Enable verbose logging

Output

{
  "track_state": { ... },
  "checks": {
    "type1": {
      "passed": true,
      "check_target": "active",
      "check_target_source": "auto",
      "matching_zones": ["79"],
      "matching_zone_count": 1,
      "zone_details": {
        "79": {
          "zone_id": "79",
          "zone_name": "op120-zone",
          "source": "active",
          "passed": true,
          "thresholds": {
            "intersection": {
              "enabled": true,
              "operator": ">=",
              "threshold": 10,
              "actual": 59.25,
              "passed": true,
              "unit": "%"
            },
            "dwellTime": {
              "enabled": true,
              "operator": ">=",
              "threshold": 300,
              "actual": 360,
              "passed": true,
              "unit": "seconds"
            },
            "velocity": {
              "enabled": true,
              "operator": "<",
              "threshold": 5,
              "actual": 1.2,
              "passed": true,
              "unit": "px/s"
            }
          }
        }
      },
      "zones_checked": ["79"],
      "zones_not_configured": ["42"],
      "zones_not_found": []
    }
  }
}

Key output fields

Field	Description
`passed`	Whether any zone met all thresholds
`matching_zones`	Zone IDs that passed
`zone_details`	Per-zone breakdown showing each threshold’s actual vs. configured value
`zones_checked`	Zones that were evaluated (had threshold config and were present in input)
`zones_not_configured`	Zones the track was in but had no threshold config
`reason`	If failed: `no_zones_configured`, `no_zones_data_in_input`, `no_zones_met_all_thresholds`, etc.

Business use case examples

Obstruction detection — dwell + intersection + velocity

Detect vehicles (forklifts, tuggers, AMRs) blocking factory aisles. A vehicle is considered an obstruction when it has been in an aisle zone for an extended period with low velocity.

Threshold	Operator	Value	Purpose
Intersection	`>=`	`10%`	Vehicle bounding box must overlap the zone
Dwell Time	`>=`	`300s` (5 min)	Vehicle must have been stopped for at least 5 minutes
Velocity	`<`	`5 px/s`	Vehicle must be stationary or near-stationary

Mode: Batch — only need the track summary after the vehicle leaves.All three thresholds are enabled, so a zone only passes if all three conditions are met simultaneously. Different aisle zones can share a single threshold group if they have the same criteria, or use separate groups for zones with different dwell time requirements (e.g., loading docks allow longer stops).See the Obstruction Workflow guide for the full end-to-end walkthrough.

Failure to stop — velocity only, multiple threshold groups

Detect vehicles that fail to come to a complete stop at designated stop sign zones. This is a compliance monitoring pattern — every vehicle passing through creates an event, either compliant or non-compliant.

Threshold	Operator	Value	Purpose
Velocity	`<=`	`25–120 px/s` (varies)	Vehicle’s average velocity must be at or below the zone’s speed threshold

Mode: Batch — only need the track summary after the vehicle passes through.The key detail: 10 separate threshold groups with different velocity values. Zones near intersections have lower thresholds (stricter stops), while zones in high-traffic corridors have higher thresholds. Each stop zone is assigned to exactly one group.A code node downstream preserves the original pass/fail result as threshold_passed, then overrides type1.passed = true so that both compliant and non-compliant tracks flow through to event creation. The event subtype is set dynamically based on the saved result.

PPE zone pre-filter — intersection only

As a pre-filter in the PPE compliance workflow, Type I determines whether a person is in a designated PPE zone before evaluating whether they’re wearing PPE (via a Type III check).

Threshold	Operator	Value	Purpose
Intersection	`>=`	`10%`	Person must be in a PPE-required zone

Mode: Batch — using person and PPE tags together so interactions are calculated.Only intersection is enabled — no dwell time or velocity requirements. The check simply answers “is this person in a zone that requires PPE?” Tracks that fail are dropped via an early-exit Switch node before running the more expensive Type III interaction check.This demonstrates how Type I can be used as a lightweight filter in a multi-check composition (Type I → Type III → VLM fallback).

Adapting thresholds for other use cases

Type I is the most flexible check node — different threshold combinations serve very different use cases:

Use Case	Intersection	Dwell Time	Velocity
Aisle obstruction	`>= 10%`	`>= 300s`	`< 5 px/s`
Loading dock overstay	`>= 20%`	`>= 1800s`	`< 2 px/s`
No-park zone violation	`>= 10%`	`>= 60s`	`< 3 px/s`
Zone intrusion	`>= 5%`	—	—
Speeding in zone	`>= 10%`	—	`> 200 px/s`
Stop compliance	—	—	`<= 50 px/s`

The key principle: enable only the thresholds you need for your specific use case. Fewer enabled thresholds means a broader match.

Active vs. historical zones

Check Target	Source	When
Active	`zones.active`	Streaming/live — zones the track is currently in
History	`zones.history`	Batch/expired — zones the track was previously in

For historical zones, the node uses “any entry passes” logic — if a track visited the same zone multiple times, only one entry needs to pass all thresholds.

Credentials

Requires GraphQL Subscription API credentials (for loading site/zone options).

Trigger Nodes

Check Nodes

Event Nodes

Action Nodes

When to use

How it works

Configuration

Site

Threshold groups

Advanced settings

Output

Key output fields

Business use case examples

Active vs. historical zones

Credentials

​When to use

​How it works

​Configuration

​Site

​Threshold groups

​Advanced settings

​Output

​Key output fields

​Business use case examples

​Active vs. historical zones

​Credentials

When to use

How it works

Configuration

Site

Threshold groups

Advanced settings

Output

Key output fields

Business use case examples

Active vs. historical zones

Credentials