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

# Routing & Queues

> How charges are routed to queues and how queues roll up to case, court, and search level

Routing happens in two stages:

1. **Per-charge routing.** Each charge is scored on **Reportability** and **Identity Match** and assigned a `routing.queue`.
2. **Hierarchical rollup.** Charge-level queues bubble up into `case_queue`, `court_queue`, and the top-level `search_queue` using a fixed precedence.

## Queue Categories

Every queue field in the response — per-charge `routing.queue`, `case_queue`, `court_queue`, and `search_queue` — uses these values:

| Queue                 | Meaning                                                 |
| --------------------- | ------------------------------------------------------- |
| **Automation**        | Charge can be fully automated with no human review      |
| **Auditor**           | Charge requires manual audit/verification               |
| **Insufficient Data** | Charge lacks enough information to make a determination |

## Charge-Level Routing Matrix

Routing is driven by whether the identity **matches** the candidate (`id_match.is_match`) and the charge's **reportability**:

| Identity                            | Reportable        | Not Reportable | Reportability Not Enough Info |
| ----------------------------------- | ----------------- | -------------- | ----------------------------- |
| **Matches** (`is_match: true`)      | Auditor           | Automation     | Auditor                       |
| **Does not match** (`Not Matching`) | Automation        | Automation     | Automation                    |
| **Insufficient identity data**      | Insufficient Data | Automation     | Insufficient Data             |

## Overrides

**Exclusion Filter:** If any `cited_rules` entry contains `EXCLUSION_FILTER`, the charge is forced to **Not Reportable** and routed directly to **Automation**, bypassing the matrix.

**Validation Issues:** Data-quality issues at candidate, case-subject, case, or offense level (surfaced in the response under `validation.issues.errors`) can force identity or reportability to **Not Enough Info**, routing the charge to **Insufficient Data**.

## Per-Charge Routing Fields

Each charge in the response includes a `routing` object:

| Field                        | Description                                                                                                   |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------- |
| `queue`                      | `Automation`, `Auditor`, or `Insufficient Data`                                                               |
| `reportability`              | `Reportable`, `Not Reportable`, or `Not Enough Info`                                                          |
| `is_automatable`             | `true` only when queue is `Automation`                                                                        |
| `identity_level`             | `High`, `Medium`, `Not Enough Info`, or `Not Matching` (≥ 0.9 → High; 0.7–0.89 → Medium; ≤ −1 → Not Matching) |
| `identity_score`             | Identity match score (0–1)                                                                                    |
| `identity_insufficient`      | `true` when identity data is too sparse                                                                       |
| `reportability_insufficient` | `true` when offense data is too sparse                                                                        |
| `third_id_required`          | `true` when a third identity factor is required                                                               |

## Hierarchical Queue Rollup

In addition to the per-charge `routing.queue`, the response surfaces aggregated queues at each level of the decision hierarchy:

| Field          | Where it lives                                              | Aggregates over           |
| -------------- | ----------------------------------------------------------- | ------------------------- |
| `case_queue`   | each entry in `decision.court_decisions[].case_decisions[]` | every offense in the case |
| `court_queue`  | each entry in `decision.court_decisions[]`                  | every case in the court   |
| `search_queue` | top-level `decision` object                                 | every case in every court |

### Precedence

Rollup uses this fixed precedence (highest priority first):

1. **`Insufficient Data`** — if any child queue is `Insufficient Data`, the parent is `Insufficient Data`
2. **`Auditor`** — otherwise, if any child queue is `Auditor`, the parent is `Auditor`
3. **`Automation`** — parent is `Automation` only when **every** child is `Automation`

In other words: a single charge missing data is enough to mark the whole case (and therefore court and search) as `Insufficient Data`. A single charge needing audit is enough to escalate the whole case. The full search rolls up to `Automation` only when there is nothing that needs human eyes anywhere in the record.

### Worked example

A search with three charges:

| Charge | `routing.queue` |
| ------ | --------------- |
| A      | Automation      |
| B      | Automation      |
| C      | Auditor         |

…rolls up to `case_queue: Auditor` → `court_queue: Auditor` → `search_queue: Auditor`.

If charge C is instead `Insufficient Data`, the whole search becomes `search_queue: Insufficient Data`.

If all three charges are `Automation`, the search rolls up to `search_queue: Automation`.

<Note>
  Use the per-charge `routing.queue` to drive **per-offense** behavior in your system. Use `case_queue`, `court_queue`, or `search_queue` when you need a **single** workflow decision at the case, court, or whole-search level without iterating over every charge.
</Note>

## Related

* [Evaluate](/api-reference/endpoints/evaluate) — Single record evaluation with full response structure
* [Glossary](/glossary) — Decision values and compliance terminology