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

# QA

> Run automated quality analysis on calls after they end

The QA node scores your calls automatically once they finish. Use it to check whether the conversation went well, flag calls that need a human to review them, or pull structured insight out of transcripts at scale.

Analysis runs **after the call ends**, as a background job. It never affects the live conversation.

## Adding a QA node

Add a QA node to your workflow from the builder, then write the analysis criteria you want applied. The criteria are a prompt: describe what to look for and what to return.

Ask for JSON. These four fields are recognised and shown as structured results:

| Field                | What it holds                                                        |
| -------------------- | -------------------------------------------------------------------- |
| `tags`               | Labels you define, each with a reason. Use for things worth flagging |
| `call_quality_score` | A numeric score                                                      |
| `overall_sentiment`  | How the conversation felt overall                                    |
| `summary`            | A short description of what happened                                 |

Anything else you return is kept in the raw response but not broken out separately.

## What gets analysed

Analysis is **per node**, not per call. Each node the conversation passed through is scored on its own, so you can see which part of the workflow went wrong rather than just that something did.

A result for one node looks like this:

```json theme={null}
{
  "node_name": "Brand Discovery",
  "tags": [],
  "summary": "The assistant initiates the brand discovery session and, upon hearing the user's interest in voice agents, overwhelms the user by asking four distinct questions in a single turn.",
  "score": 6,
  "overall_sentiment": "neutral"
}
```

Tags raised by any node are also collected into a single list for the whole run, so you can filter for a tag without inspecting each node.

## Choosing the model

By default QA uses the same LLM as the workflow. Turn that off to pick a different provider, model, and key for analysis alone — useful when you want a cheaper model for scoring than for talking, or a stronger one.

QA analysis is a separate LLM call. Its token usage is added to the run's usage breakdown under `QAAnalysis`, so you can see exactly what each analysis cost.

## Controlling which calls are analysed

Analysing every call gets expensive at volume. Three settings limit it:

| Setting               | Default      | What it does                                            |
| --------------------- | ------------ | ------------------------------------------------------- |
| Minimum call duration | `15` seconds | Calls shorter than this are skipped                     |
| Sample rate           | `100%`       | Analyse only this percentage of calls, chosen at random |
| Voicemail calls       | Off          | When off, calls that reached voicemail are skipped      |

You can also disable a QA node entirely without deleting it.

## Viewing results

Open the **Run Detail** page for any run to see its QA results.

If you are reading runs through the API, results live in the run's `annotations` field, keyed by QA node. Each node result keeps the model's `raw_response` alongside the parsed fields, so you can still see what the model said if the output was not valid JSON.

A result will tell you one of three things:

* **Analysis ran** — you get `node_results` with a result per node
* **Skipped** — the reason is included, for example a call below the minimum duration or one excluded by sampling
* **Error** — analysis was attempted and failed

## Testing your criteria

Sampling and the duration minimum both cause QA to produce nothing, which is easy to mistake for a broken node. While you are iterating on criteria, set the sample rate to 100% and the minimum duration to 0 so every test call is analysed.

Then run your criteria against several deliberately different calls — one that went well, one where the agent missed something, one that ended early. A single good call will not tell you whether your scoring actually discriminates.