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

# Type II: Zone Sequence

> Check if a track visited zones in a specific order

Type II checks evaluate whether a track traversed zones in a configured sequence. This is used for detecting directional violations, validating expected paths, or identifying tracks that skipped required checkpoints.

## When to use

Use Type II for any use case where the core question is "did this object travel through zones in this order?":

* **Wrong-way detection** — track visited zones in the reverse of the expected direction
* **Checkpoint validation** — track passed through required zones before entering a restricted area
* **Path compliance** — track followed the expected route through a facility
* **Entry/exit patterns** — track entered through a specific zone and exited through another

## How it works

1. The node builds the track's **zone sequence** — the chronological order of zones visited
2. For each configured sequence, it checks if the zones appear in that order within the track sequence
3. **Bypass zones** can invalidate a match if they appear between sequence zones
4. The check passes if **at least one** configured sequence matches

## Configuration

### Site

Select the Worlds site to load available zones.

### Zone sequences

Define one or more sequences to check for. Each sequence contains:

| Parameter        | Description                                                                             |
| ---------------- | --------------------------------------------------------------------------------------- |
| **Zones**        | Ordered list of zone IDs. The first zone is the start, the last is the **target zone**. |
| **Bypass Zones** | Optional. Zones that invalidate the match if visited between sequence zones.            |

<Note>
  Each sequence requires at least 2 zones. The **last zone** in the sequence is the target zone — it gets added to `matching_zones` when the sequence matches.
</Note>

### Match mode

| Mode                      | Description                                                                                                                      |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Ordered** (recommended) | Zones must appear in order, but other zones can appear between them. Sequence \[A, C] matches in path \[A, B, C].                |
| **Exact**                 | The last N zones must match exactly. Sequence \[A, C] only matches if the last 2 zones visited are \[A, C] with nothing between. |

### Advanced settings

| Parameter        | Default | Description                                                        |
| ---------------- | ------- | ------------------------------------------------------------------ |
| **Check Target** | Auto    | `auto` uses history + active for streaming, history only for batch |
| **Debug Mode**   | false   | Enable verbose logging                                             |

## Bypass zones

Bypass zones provide a way to invalidate a sequence match. If a track visited a bypass zone between any two zones in the sequence, the match is invalidated.

**Example — wrong-way detection with exception:**

* Sequence: \[Zone A, Zone B] (expected forward direction)
* Bypass zones: \[Security Checkpoint]
* Track path: Zone A → Security Checkpoint → Zone B
* Result: **No match** — the security checkpoint between A and B invalidates the sequence

This is useful for cases where a specific intermediate zone means the traversal was authorized.

## Output

```json theme={null}
{
  "track_state": { ... },
  "checks": {
    "type2": {
      "passed": true,
      "check_target": "active",
      "check_target_source": "auto",
      "matching_zones": ["zone_b"],
      "matching_zone_count": 1,
      "track_sequence": ["zone_a", "zone_c", "zone_b"],
      "sequences": [
        {
          "zones": ["zone_a", "zone_b"],
          "target_zone": "zone_b",
          "passed": true,
          "match_positions": [0, 2],
          "intermediate_zones": ["zone_c"],
          "bypass_zones_found": []
        }
      ]
    }
  }
}
```

### Key output fields

| Field            | Description                                                                                |
| ---------------- | ------------------------------------------------------------------------------------------ |
| `passed`         | Whether any configured sequence was found in the track's zone history                      |
| `matching_zones` | Target zones (last zone) of matching sequences                                             |
| `track_sequence` | The full zone sequence the track traversed                                                 |
| `sequences`      | Per-sequence results with match positions, intermediate zones, and bypass zone details     |
| `reason`         | If failed: `no_sequences_configured`, `empty_track_sequence`, `no_sequences_matched`, etc. |

## Business use case examples

<Accordion title="Wrong-way detection — single zone sequence">
  Detect vehicles traveling in the wrong direction through one-way aisles. Each sequence defines an approach zone and a target zone representing the **wrong** direction.

  | Parameter        | Value                         |
  | ---------------- | ----------------------------- |
  | **Sequence**     | \[Approach Zone, Target Zone] |
  | **Bypass Zones** | None                          |
  | **Match Mode**   | Ordered                       |

  **Mode:** Batch — only need the track summary after the vehicle passes through.

  If a vehicle visits the approach zone before the target zone (in the wrong direction), the sequence matches and the check passes. Multiple sequences can be configured for different one-way aisles across the site.

  <Tip>
    Define the sequence in the **wrong** direction. The check passing means the violation occurred.
  </Tip>
</Accordion>

<Accordion title="Failure to stop — directional stop sign enforcement">
  In the failure-to-stop compliance workflow, Type II is composed with Type I to enforce **directional** stop signs — stop signs that only apply when approaching from a specific direction.

  | Parameter        | Value                                                                      |
  | ---------------- | -------------------------------------------------------------------------- |
  | **Sequences**    | 13 zone pairs — \[approach zone, stop zone] for each directional stop sign |
  | **Bypass Zones** | None                                                                       |
  | **Match Mode**   | Ordered                                                                    |

  **Mode:** Batch — composed with a Type I velocity check upstream.

  The Type II check answers: "did this vehicle come from the approach direction before reaching the stop zone?" This is combined with the Type I velocity check via a **Check Aggregator** that defines two groups:

  | Group                                | Required Checks  |
  | ------------------------------------ | ---------------- |
  | Directional stop signs (12 zones)    | Type I + Type II |
  | Non-directional stop signs (4 zones) | Type I only      |

  This demonstrates how Type II is often a **secondary check** that adds directional context to a primary check, rather than standing alone.
</Accordion>

<Accordion title="Adapting for other use cases">
  Zone sequences can model any path-based validation:

  | Use Case               | Sequence Definition                               | Notes                                 |
  | ---------------------- | ------------------------------------------------- | ------------------------------------- |
  | Wrong-way detection    | \[Approach, Target] in wrong direction            | Passing = violation                   |
  | Directional compliance | \[Approach, Checkpoint] in correct direction      | Passing = compliant                   |
  | Checkpoint validation  | \[Entry, Checkpoint A, Checkpoint B, Destination] | Multi-step sequence                   |
  | Restricted access      | \[Public Area, Restricted Zone]                   | With bypass zone for authorized paths |

  Use **bypass zones** when certain intermediate zones should invalidate the match — for example, passing through a security checkpoint between zones means the traversal was authorized.
</Accordion>

## Credentials

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