> ## 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. # Queue & Decision → Next Action > What to do with queue and/or decision outcomes in your CRA workflow **One signal is usually enough.** At rollup levels, queue and decision are paired (`Automation` ↔ `NOT_REPORTABLE`, `Auditor` ↔ `REPORTABLE`, `Insufficient Data` ↔ `MANUAL_REVIEW`), so do not branch twice on both for the same if/else. | Signal | Question it answers | Typical fields | | ------------ | ---------------------------------- | ----------------------------------------------------------------------- | | **Queue** | Where should this work go next? | `routing.queue`, `search_queue`, `case_queue`, `court_queue` | | **Decision** | What is the reportability outcome? | `charge_decision`, `record_decision`, `case_decision`, `court_decision` | | Pattern | When… | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Queue only** | You route work to desks / queues (automation vs auditor vs data review) | | **Decision only** | You key off reportability labels (clear / consider / manual review) | | **Both** | Only when they do **different jobs** — e.g. queue for routing, decision for report/UI labeling. Not two copies of the same branch. | | Level | Queue field | Decision field | | ------------ | ---------------------------- | ---------------------------------- | | Per charge | `routing.queue` | `charge_decision` | | Whole search | `search_queue` | `record_decision` | | Case / court | `case_queue` / `court_queue` | `case_decision` / `court_decision` | How queues are assigned and rolled up: [Routing & Queues](/api-reference/routing). *** ## Queue → recommended action Use when you consume **queue** (alone or with decision). | Queue | Meaning | Recommended customer action | | --------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Automation** | No human review needed | Auto-complete in your CRA workflow. Typically clear / exclude not-reportable charges; do not open an auditor queue. | | **Auditor** | Human review recommended | Route to a human auditor before including the search (or charge) in a consumer report. Use `rationale`, `cited_rules`, and `citations` as the audit packet. | | **Insufficient Data** | Human review required — data too sparse for automation | Do **not** auto-report. Inspect `validation.issues` (when present). Fix source data and [resubmit](/guides/resubmission) with `record_json`, **or** send to a human data-review queue if you cannot correct the payload. | **Rollup priority:** `Insufficient Data` > `Auditor` > `Automation`. One charge in `Insufficient Data` escalates the case, court, and search. *** ## Decision → recommended action Use when you consume **decision** (alone or with queue). At **aggregated** levels (`record_decision`, `court_decision`, `case_decision`), decision mirrors queue: | Decision | Paired queue (rollup) | Recommended customer action | | ------------------- | --------------------- | ------------------------------------------------------------------------------------- | | **NOT\_REPORTABLE** | `Automation` | Treat as cleared for automation — typically exclude from the consumer report. | | **REPORTABLE** | `Auditor` | Eligible to report — route through your audit / disclosure process before publishing. | | **MANUAL\_REVIEW** | `Insufficient Data` | Do not auto-complete. Investigate data (or resubmit) before finishing. | Per-charge `charge_decision` works the same way for offense-level reportability. Note: identity match can change **queue** relative to a naive decision-only rule — if your workflow is desk/routing based, prefer the **queue** tables instead. *** ## Using rationale, cited\_rules, and citations These live on each offense under `decision.court_decisions[].case_decisions[].offenses[]`: | Field | What it is | How to use it | | ------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------- | | `rationale` | Human-readable explanation of the charge outcome | Show to auditors; log for disputes / QC | | `cited_rules` | Internal rule IDs that fired (e.g. `GENERAL_TRAFFIC_NON_REPORT`) | Traceability, regression tests, support tickets | | `citations` | Legal statute references when the engine provides them (may be `[]`) | Attach to audit notes when present; do not invent statutes if empty | For **Auditor** / **REPORTABLE** paths, treat these three fields as the default audit packet alongside identity match (`id_match`) and `routing` detail. For **Automation** / **NOT\_REPORTABLE**, you usually do not need a human to read them — still persist them for audit trails. For **Insufficient Data** / **MANUAL\_REVIEW**, prefer `validation.issues` for *what is missing*; use `rationale` for the narrative why automation stopped. *** ## Resubmit vs human review | Situation | Prefer | | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Missing / wrong mapped fields you can fix (disposition, charge text, DOB, SSN, address) | [Resubmit](/guides/resubmission) with corrected `record_json` + `submission_type: "resubmit"` | | Vendor XML was incomplete and you have corrected mapped criminal JSON | Resubmit (`record_json` only — no `xml`) | | Data cannot be fixed in your system (court record genuinely sparse, need researcher) | Human review / data acquisition — do not loop empty resubmits | | Queue is `Auditor` **or** decision is `REPORTABLE`, and data looks complete | Human **audit** of reportability — usually **not** a resubmit | | Queue is `Automation` **or** decision is `NOT_REPORTABLE` | No resubmit; complete automatically | Resubmission is **optional**. Most integrations send one evaluate and stop. Details: [Resubmission Workflow](/guides/resubmission). *** ## Related * [Quickstart — understand the response](/quickstart#step-5-understand-the-response) * [Evaluate response](/api-reference/endpoints/evaluate#response) * [Routing & Queues](/api-reference/routing) * [Sample Pack](/samples/overview)