Build a Version-Locked Human Review Queue

What you will complete

Complete the review queue schema, status transitions, authority matrix, reviewer actions, service targets, and escalation policy.

Show the whole decision package

Each queue item should show the original document, source pointer, extracted and normalized values, confidence where available, validation results, duplicate evidence, exception reasons, correction history, current version, owner, reviewer, due time, and downstream state. Hiding uncertainty behind a single “review needed” label slows decisions and weakens the audit trail.

Recommended actions are approve, reject, request correction, request information, and escalate. Require a reason for rejection, requested changes, overrides, and unusual approvals. Preserve the original recommendation and values when a person corrects them.

A useful status model distinguishes received, validating, ready for review, in review, approved, rejected, changes requested, duplicate, stale version, exception, downstream queued, downstream done, and cancelled. Keep document-processing state separate from a platform’s moderation, signature, or payment state.

Bind decisions to authority and version

Record expected approver, actual actor, decision, time, comment, route policy, version or ETag, and decision ID. An anonymous click, chat reaction, or free-text status is not enough unless the system maps it into this evidence and verifies authority.

If the file changes after review begins, compare the current version with the frozen review version. A mismatch makes the decision stale. Start a new cycle for the current content. Do not carry approval forward because the filename stayed the same.

A timeout must never approve. Remind, reassign, escalate, cancel, or keep the item pending according to a written policy. If everyone is unavailable, the queue needs a named watcher and escalation owner.

Worked example: conflicting total review

Fictional example: Cedar & Quay’s reviewer opens INV-TP-2404. The queue shows the original source values, calculated 220.50, printed 185.00, conflicting_total, supplier identity, source hash, and current version. The reviewer can reject it, request a corrected invoice, or use an authorized override path with a reason.

While that item is open, a replacement invoice arrives with a changed total. The old review request becomes stale_version. The replacement receives a new request ID and must pass validation again. The earlier approval cannot release it.

A finance clerk attempts to approve an amount outside their authority. The queue records unauthorized_approver, makes no destination call, and routes the case to the approved reviewer.

Complete Workbook Section 4

1. Define queue fields and views for ready, exception, overdue, stale, and completed work.
2. Write allowed transitions and reviewer actions.
3. Name expected authority and the evidence stored for every decision.
4. Define edit, stale-version, timeout, absence, and escalation behavior.
5. Specify correction history and what the reviewer must see before deciding.

Use Section 4 of the workbook.

Review design failures

• Sending a notification without creating an owned queue item.
• Showing values without the original source.
• Allowing edits while preserving an earlier approval.
• Treating timeout as rejection or approval without a stated policy.
• Using the same person for incompatible entry, approval, payment, and reconciliation duties without compensating review.

Module 5 uses this approval evidence to control destination writes and recovery.

Check your application