Emerging

Verification handoff

The system names exactly what a human should double-check, turning blanket doubt into one task.

MTicket #4821Reply to Dana Ortiz 2 things to check

To dana@ortizstudio.co Drafted by Milky

Hi Dana,

Sorry about the double charge on 14 August. I've refunded $1,240.00 to your card ending 4417. It should reach your account within 3–5 business days.

You won't be charged again for August.

Thanks for your patience,
Maya

Check these before sending

Dana's card was issued in Canada. Milky's source only covers US cards, where 3–5 days is right.

This is a promise. Milky couldn't confirm the August renewal (invoice #8823) was voided.

Milky checked the rest: amount matches invoice #8822, card ending 4417, date 14 Aug.

Try it: Milky checked most of the reply itself and hands you the two parts it couldn't. Resolve both and Send unlocks.

In the wild

How one product ships this pattern. Click a screenshot to enlarge it.

Rossum invoice validation screen with an 'Automation blockers' panel listing three fields to check: Code below the 65% threshold, Total Amount built-in checks failed, Tax Point Date required — Rossum
Instead of asking for a full review, Rossum lists the specific fields that stopped automation and why, so the reviewer checks only those.
Source: Rossum knowledge base ↗

When to use

Outputs that are mostly right but carry a specific risky element — a figure, a name, a legal clause.

Seen in

Contract review copilots, invoice extraction QA, medical scribe review steps.

For engineers

Derive the check list from low-confidence fields, not from a static template.

Build prompt

A neutral, component-only prompt for a coding agent. Edit the stack block or anything else to fit your project, then copy it.

# Build the "Verification handoff" pattern: `VerificationChecklist`

## Stack (edit this block to match your project)
- React 18+ with TypeScript: one function component, typed props, no `any`.
- Tailwind CSS, using your design system's tokens if you have them.
- Presentational only: data comes in through props, decisions go out through callbacks. No fetching or global state inside.
- If your codebase already has conventions (naming, shared components, tokens), follow them over this spec.

## What the pattern is for
The system names exactly what a human should double-check, turning blanket doubt into one task.

Use it when: Outputs that are mostly right but carry a specific risky element — a figure, a name, a legal clause.

## What to build
A short, specific list of the items in an AI output that a person should check, each tied to the exact phrase or value, with the reason it is uncertain and one-click resolutions. It also states what the system already checked, and enables the dependent action once every item is resolved. It renders beside a draft message, document or form before it is sent or submitted.

### Props
- `items`: Array<{ id: string; quote: string; anchorId: string; reason: string; resolutions: Array<{ id: string; label: string; kind: "keep" | "change" | "remove"; replacement?: string }> }>, derived from low-confidence or unsupported parts of the output.
- `alreadyChecked?`: string, what passed automatic checks, e.g. "Amount matches invoice #2210, card ending 5521".
- `resolved`: Record<string, { resolutionId: string; by: string }>, controlled.
- `onResolve(itemId: string, resolutionId: string)`: the parent applies any text change. The component never edits the output itself.
- `activeItemId?`: string and `onActivate(itemId: string | null)`, to highlight the matching phrase in the output.
- `action`: { label: string; onConfirm(): void }, e.g. "Send reply", enabled when all items are resolved.

### States it must render
- Open items: a header "2 things to check" and numbered items, each quoting the phrase ("3 to 5 business days"), the specific reason ("The card was issued in Canada; the source only covers US cards"), and resolution buttons; the action is disabled.
- Item active: the quoted phrase is highlighted in the output and the item is outlined.
- Item resolved: the item collapses to "Checked by you" or "Changed by you" and the phrase shows its new state in the output.
- All resolved: the header turns green "Ready to send" and the action enables.
- Nothing to check: a single green line with `alreadyChecked`, and the action enabled; no generic disclaimer.

### Interactions
- Clicking an item or hovering its phrase in the output calls `onActivate` to link the two.
- Each resolution button calls `onResolve`; "keep" resolutions are labelled as a claim of checking, e.g. "I checked, keep it".
- Arrow keys move between items; the next unresolved item gets focus after one is resolved.

### Edge cases
- More than 5 items means the output is not "mostly right": show a notice suggesting a full review instead of a long checklist.
- The parent regenerates the output: items whose quote no longer appears are dropped, and new ones appear unresolved.
- Two items on overlapping text: highlight each separately and resolve independently.
- A resolution that changes text creates new uncertainty: the parent may add a new item, which appears unresolved.

## Must avoid
A generic "AI can make mistakes" footer that shifts responsibility without directing attention.

## Engineering constraint
Derive the check list from low-confidence fields, not from a static template.

## Accessibility
- Each item is linked to its phrase with `aria-describedby`; the phrase is focusable and announces "needs checking".
- Announce the remaining count after each resolution and when the action becomes available.

## House rules
- Real `<button>`/`<input>` elements, full keyboard use, visible focus; announce status changes with `aria-live="polite"`; respect `prefers-reduced-motion`.
- All user-facing text comes from props (or a `labels` prop) so it can be translated.
- One consistent accent marks anything the AI made or is doing; amber means "needs a person", red means risky, green means done. Never rely on colour alone.
- Fits a 360 px wide container without horizontal scrolling.

## Acceptance checks
- [ ] Every state above can be rendered by passing props, with no internal fake data.
- [ ] Every interaction and edge case above behaves as described.
- [ ] Nothing in "Must avoid" can happen with this component.

## Deliver
1. The component file with its exported prop types.
2. A short usage example that renders each state.

Download this prompt as Markdown, or every prompt as JSON for an agent.

Critique checklist for trust indicators

0 of 4 checked

These questions apply to every pattern in this family. Ticks are saved in this browser.

Can a claim be traced to a source in one click?
Does uncertainty change the interface, not just the wording?
Is confidence calibrated, or decorative?
Does the design make verification cheaper than re-doing the work?