> ## Documentation Index
> Fetch the complete documentation index at: https://docs.worlds.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Check Types Overview

> The three composable check types that form the foundation of every Worlds workflow

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](/nodes/detection-webhook-trigger):

| Signal Type     | Check Node                                                    | Question it answers                  |
| --------------- | ------------------------------------------------------------- | ------------------------------------ |
| **Track State** | [Track Checks](/nodes/type-1-track-in-zone) (Type I, II, III) | "What is this specific track doing?" |
| **Zone State**  | [Zone Activity Check](/nodes/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.

<Columns cols={3}>
  <Card title="Type I" icon="location-dot" href="/nodes/type-1-track-in-zone">
    **Track in Zone**

    Is a track in a zone meeting threshold conditions?
  </Card>

  <Card title="Type II" icon="route" href="/nodes/type-2-zone-sequence">
    **Zone Sequence**

    Did a track visit zones in a specific order?
  </Card>

  <Card title="Type III" icon="people-arrows" href="/nodes/type-3-track-interaction">
    **Track Interaction**

    Did two tracks interact with each other?
  </Card>
</Columns>

## Zone Activity Check

<Card title="Zone Activity" icon="chart-area" href="/nodes/zone-activity-check">
  **Zone Activity Check**

  Are enough tracks in a zone meeting threshold conditions? Used for congestion, congregation, and occupancy monitoring.
</Card>

## 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:

```json theme={null}
{
  "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.