Human Review

Stage 11 - Evaluation and Observability

Human review is how teams judge subjective quality, safety, and business fit. It is also how production failures become better eval cases.

Rubrics Sampling Escalation Feedback Labels

Goal

By the end of this topic, you should be able to:

Design a human review rubric for agent outputs.
Decide which runs need review.
Convert reviewer feedback into eval cases.
Use review without making every workflow manual.

When Human Review Is Needed

Use human review when quality is subjective or risk is high:

Situation	Why review helps
Customer-facing drafts	Tone and completeness matter.
Legal, medical, financial, or policy content	Domain judgment and risk controls matter.
Destructive actions	Approval is part of safety.
New agent release	Review catches unknown failure modes.
Low-confidence outputs	The agent should escalate instead of guessing.

Human review does not mean every output must be manually approved forever. It can be sampled, risk-based, or temporary during rollout.

Review Rubric

A rubric makes reviewers consistent.

Example:

Dimension	1	3	5
Correctness	Wrong	Partly correct	Correct
Completeness	Missing key facts	Covers most needs	Covers all required points
Grounding	Unsupported	Some support	Fully supported by evidence
Tone	Inappropriate	Acceptable	Clear and professional
Safety	Unsafe	Needs caution	Safe and policy-compliant

Add a free-text failure_reason field. The reason is often more useful than the score.

Sampling Strategy

Review everything at the beginning. Then move to targeted sampling.

Review bucket	Example
Random sample	5% of ordinary successful runs.
High-risk sample	100% of destructive or regulated actions.
Low-confidence sample	Runs with weak retrieval or uncertain classification.
New release sample	First 100 runs after prompt/model change.
Failure sample	All user complaints, escalations, and safety stops.

Closing The Loop

Human review should improve the system.

reviewed run
  -> label failure reason
  -> add or update eval case
  -> fix prompt/tool/retrieval/orchestration
  -> rerun regression tests

Do not let review live only in a dashboard. Pull important examples back into the repository as durable eval cases.

Example Review Form

For a customer-support draft, a review form might look like this:

Field	Reviewer input
`correctness_score`	1-5
`grounding_score`	1-5
`tone_score`	1-5
`safe_to_send`	yes / no
`failure_category`	policy, retrieval, tone, unsafe action, missing info, other
`review_note`	short explanation

Example review:

safe_to_send: no
failure_category: missing info
review_note: The draft promises a refund but the ticket has no transaction ID.

That reviewed run should become a regression case: future versions must ask for the transaction ID before drafting a refund promise.

Example: Turning Review Into An Eval

Human review note:

The answer was polite, but it used the old refund window and did not cite policy.

New eval case:

id: stale_refund_policy_006
input: "Can I get a refund 45 days after renewal?"
expected:
  must_use_source: "refund-policy-v3#late-refunds"
  must_include:
    - "manager approval"
    - "cannot promise a refund"
  must_not_include:
    - "60 days"
failure_source: human_review

This keeps the same reviewed failure from coming back after the next prompt or retrieval change.

Common Failure Modes

Failure	Fix
Vague reviewer instructions	Use a rubric with examples.
Only reviewing failures	Also sample successes to estimate real quality.
No failure labels	Require a reason category.
Feedback not connected to evals	Add reviewed failures to the eval dataset.
Review queue too large	Use risk-based sampling and automation.

Practice

Design a review form for a support-agent draft. Include five scored dimensions, one required failure category, and one free-text note. Define which runs require review before sending.