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

# Results

> How Synthpop reports what it found: per-code verdicts, the issues behind them, and a plain-English conclusion — all linked on the Task.

When a validation [Task](/concepts/tasks) reaches a terminal status, Synthpop
reports its findings in three linked places on `TaskDetails`:

* **`verdicts`** — the per-code decision: approved or not.
* **`issues`** — the specific problems Synthpop found, which verdicts point at.
* **`verdict_summaries`** — a per-code human-readable conclusion.

Think of this as a **result**, not a bare pass/fail: a decision, its supporting
issues, and an explanation, all in one response.

<Note>
  `verdicts` and `verdict_summaries` are empty on a freshly created Task and are
  populated only once processing finishes. Poll `GET /task/get` to a terminal
  status, or use a callback. See [Async results](/guides/async-results).
</Note>

## Verdicts

A `Verdict` is the decision for one code (e.g. an HCPCS procedure code or an
`Exxxx` code).

<ResponseField name="code" type="string" required>
  The code being evaluated.
</ResponseField>

<ResponseField name="approved" type="boolean" required>
  Whether the code was approved.
</ResponseField>

<ResponseField name="issues" type="integer[]" required>
  **Indices into `TaskDetails.issues`** — pointing at the issues that affect this
  verdict and may have caused it not to be approved. This is a list of array
  positions, not issue objects.
</ResponseField>

### The index linkage

A verdict does not embed its issues — it references them by position. To resolve
them, index into the Task's top-level `issues` array:

```json theme={null}
{
  "issues": [
    { "key": "task.medical_record.expired", "medical_record_type": "clinical-note", "message": "The clinical note is older than the allowed window." },
    { "key": "task.data.missing", "property": "physician_signature", "message": "The order is missing a physician signature." }
  ],
  "verdicts": [
    { "code": "70551", "approved": false, "issues": [0, 1] }
  ]
}
```

Here verdict `70551` (an *illustrative example* code) was not approved, and its
`issues: [0, 1]` point at the two entries in `issues` — the expired clinical note
and the missing signature.

<Warning>
  The indices are positions in **this response's** `issues` array. Resolve them
  against the same payload; do not cache indices across separate reads, since the
  array can change as processing progresses.
</Warning>

## Issues

`TaskDetails.issues` is a list of problems detected with the Task or its medical
records. It is a **discriminated union** keyed by the `key` field — every issue
has a `key` and a human-readable `message`, plus type-specific fields. There are
nine issue types:

| `key`                                    | Meaning                                                         | Extra fields                      |
| ---------------------------------------- | --------------------------------------------------------------- | --------------------------------- |
| `task.data.missing`                      | A required input data item is missing.                          | `property`                        |
| `task.data.inconsistent`                 | Inconsistent data found across documents.                       | `property`                        |
| `task.medical_record.missing`            | A required medical record type is missing.                      | `medical_record_type`             |
| `task.medical_record.expired`            | A record's service date is too far in the past.                 | `medical_record_type`             |
| `task.medical_record.incorrect_sequence` | The sequence of documents does not meet requirements.           | `medical_record_type`             |
| `task.logic.fail`                        | A deterministic logic check failed.                             | `code`                            |
| `task.logic.warning`                     | A deterministic logic check raised a warning.                   | `code`                            |
| `task.llm.other`                         | A generic issue reported during analysis.                       | —                                 |
| `medical_record.data.missing`            | Required information is missing from a specific medical record. | `property`, `medical_record_type` |

<Note>
  Switch on `key` to handle each issue type. The union is the single source of
  truth for what can appear — new issue types would appear as new `key` values.
</Note>

<Expandable title="Example issue objects">
  ```json theme={null}
  [
    {
      "key": "task.data.missing",
      "property": "physician_signature",
      "message": "The order is missing a physician signature."
    },
    {
      "key": "task.medical_record.expired",
      "medical_record_type": "clinical-note",
      "message": "The clinical note is older than the allowed window."
    },
    {
      "key": "task.logic.fail",
      "code": "70551",
      "message": "Ordered code is not supported by the diagnosis codes provided."
    }
  ]
  ```
</Expandable>

## Conclusions

For validation tasks, `verdict_summaries` gives a plain-English conclusion per
code — the sentence you can surface to a human reviewer.

<ResponseField name="code" type="string" required>
  The code the conclusion applies to.
</ResponseField>

<ResponseField name="conclusion" type="string" required>
  Human-readable conclusion summary for this code.
</ResponseField>

```json theme={null}
{
  "verdict_summaries": [
    {
      "code": "70551",
      "conclusion": "The submitted documentation supports the ordered procedure (an _illustrative example_). The required criteria are met, including a signed physician order, a supporting clinical note within the allowed window, and diagnosis codes consistent with the request."
    }
  ]
}
```

## Reading a result end to end

<Steps>
  <Step title="Check the status">
    Confirm the Task reached a terminal status (`completed`, `failed`, or
    `invalid`). A Task can also stop in `waiting` if it needs more input.
  </Step>

  <Step title="Read the verdicts">
    For each `Verdict`, look at `approved`.
  </Step>

  <Step title="Resolve the issues">
    For an unapproved verdict, map each index in its `issues` array to
    `TaskDetails.issues[i]` and switch on `key` to explain what is wrong.
  </Step>

  <Step title="Show the conclusion">
    Surface the matching `verdict_summaries` entry for a reviewer-ready sentence.
  </Step>
</Steps>

<Note>
  If a verdict is not approved because of a missing document, the Task often sits
  in `waiting` — supply the document to resume it. See
  [Responding to waiting tasks](/guides/responding-to-waiting-tasks).
</Note>

## Where to go next

<CardGroup cols={2}>
  <Card title="Tasks" icon="cube" href="/concepts/tasks">
    The resource verdicts and issues live on.
  </Card>

  <Card title="Data Items" icon="layer-group" href="/concepts/data-items">
    The inputs and extracted records behind a result.
  </Card>
</CardGroup>