---
title: "QA Review Workflow"
description: "A two-stage quality gate — review requirements one by one during fieldwork, then sign off the whole assessment at the end."
version: "en"
---

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

# QA Review Workflow

Kliper reviews an assessment in **two stages** that feed each other: reviewers QA individual **requirements** as they're completed during fieldwork, then a single **sign-off** completes the whole assessment at the end. The final sign-off knows how much requirement-level QA actually happened, so you never approve a Report on Compliance that nobody reviewed.

| Stage | Unit | When | Where |
|---|---|---|---|
| **Requirement QA** | One requirement | During fieldwork, as each is finished | Sections editor → Reviews page |
| **Assessment sign-off** | The whole assessment | At the end, once QA is complete | Reviews page |

> **Note**
>
> Reviewing is role-gated. **Admins, managers, and QA reviewers** see the review queues and can approve or send work back. Assessors submit their work for review.

## Reviewing a single requirement

### Submit for review

As an assessor, when a requirement is ready:

1. **Open the requirement**

   In the sections editor, expand the requirement card.
2. **Submit for review**

   At the foot of the card, click **Submit for review**. Its header chip turns to **In review** (blue).

> **Tip**
>
> If the requirement has no finding selected or unanswered testing procedures, Kliper asks you to confirm before submitting — so obviously-incomplete work doesn't reach a reviewer by accident. You can still submit deliberately.

### Approve or send it back

The submitted requirement appears in the **Requirement QA** panel at the top of the [Reviews page](/operations/reviews), oldest first. Each row shows its assessment, who submitted it, and a **testing-procedure completeness** stat (for example `0/2 TPs answered`, amber when incomplete) so you can see emptiness *before* approving.

- **Approve** — the requirement passes QA. Its chip turns green (**QA done**) and the submit control disappears.
- **Send back** — a dialog asks for a **note** (required). The requirement is returned to the assessor with your reason.

### Status chips and send-backs

Each requirement card carries a chip that reflects its review state:

| Chip | Meaning |
|---|---|
| *(none)* | Drafted, not yet submitted |
| **In review** | Submitted, waiting on a reviewer |
| **Sent back** | A reviewer requested changes |
| **QA done** | Approved |

When a requirement is sent back, the assessor sees an amber **Sent back by QA** callout with the reviewer's note inside the card, gets a notification that deep-links straight to it, and the button becomes **Resubmit for review**.

> **Caution**
>
> **Editing a QA-approved requirement resets it.** If you change the content of a requirement that was already approved, it drops back to *drafted* and clears its review — so **QA done** always vouches for the exact content the reviewer saw.

## The Requirement QA panel

The panel at the top of the Reviews page gives reviewers the whole picture:

- A **funnel bar per active assessment** showing how its requirements are distributed across *drafted → in review → sent back → done*, with a `N/total done` count.
- The **reviewer queue** of requirements awaiting review, each with its completeness stat and Approve / Send back actions.
- A **Sent back to you** list of your own returned requirements, each with the reviewer's note.

## Pre-QA checks on Send to QA

When you send a whole assessment to QA, Kliper first runs the deterministic checks a reviewer would otherwise do by hand:

- **In Place without any evidence** — a control marked In Place with no attached file, no inline evidence, and no cited artifact.
- **Not Applicable / Not Tested without justification** — an N/A or Not-Tested finding with an empty explanation.
- **No finding selected** — controls still undecided.
- **Assessment dates** — Section 1.2 begin/end dates missing, inverted, or outside the engagement (LOE) window.

If everything passes, the assessment submits straight through. If there are issues, a dialog groups them by rule with **jump links** to the exact control, and offers **Go fix** or **Submit anyway**. Overrides aren't silent — the reviewer's notification says the assessment was submitted with N unresolved warnings.

> **Note**
>
> The checks are advisory, not a hard gate — an assessor can always override with judgment. The point is that nothing obviously-incomplete reaches a reviewer *by accident*.

## Final sign-off

When the whole assessment is ready, it's submitted for a single **sign-off** that completes it. Awaiting-sign-off assessments appear in the **Assessments awaiting sign-off** panel on the Reviews page.

The two stages are connected: each sign-off row shows the per-requirement **QA rollup** — `N/total QA-approved`, amber while incomplete, green once every requirement has passed QA. The action reflects it too:

1. **Sign off**

   The button reads **Sign off** (distinct from the per-requirement **Approve**). It's a quiet outline button while requirements are still in QA, and becomes a solid primary button once they're all approved — so the final action lights up only when the granular work is done.
2. **Confirm if QA is incomplete**

   If requirements are still un-reviewed, Kliper warns you first (*"N of M requirements haven't passed per-requirement QA — sign off anyway?"*). You can override, but it can't happen silently.

> **Note**
>
> Signing off completes the assessment. From there you can generate the final [ROC report](/guides/roc-report).

Source: https://docs.kliper.dev/guides/qa-review-workflow/index.mdx