Module 5 Route work into human review

Time plan: 25 minutes teaching, 25 minutes worked design, 50 minutes practice and 20 minutes checks. Keep your route table and review record. Prerequisite: the field map from Module 4.

What you will be able to do

Create a complete routing decision, explain why overlapping conditions are dangerous, validate a model-produced draft and build a review handoff that cannot be bypassed by the draft itself.

Separate interpretation from permission

An assistant can propose a classification, but the next step should not blindly trust it. The workflow checks identity, field types, allowed statuses, source references and fixed policy boundaries. This is especially important when a fluent answer contains an unsupported promise. “Approved” in a model response is a validation failure, not an approval signal.

The final route and the human review state are different fields. DRAFT_READY means the content is eligible to enter the ordinary review queue. It does not mean the reviewer has approved it. Review state begins PENDING. A verified reviewer may later mark the exact draft version APPROVED_FOR_NEXT_STEP, REJECTED or REVISION_REQUESTED. Those words are labels in a training design; this course does not implement a booking or sending action.

Preview the ledger before you use it

The duplicate ledger is a small operation log. It answers “Have we already tried to create this request revision's review item?” Its key R101|1|queue_review combines the request, revision and intended operation. Read these three example entries before applying the route table:

- No matching entry: the operation has not been recorded in this training log; continue the other checks before attempting it.
- R101|1|queue_review, state RECORDED, destination Q101: a matching item was confirmed. Another identical delivery references Q101 and does not create another queue item.
- R109|1|queue_review, state STARTED or NEEDS_RECONCILIATION, destination not confirmed: an attempt may be in progress or its outcome is unknown. Hold the operation and investigate; a missing confirmation is not permission to write again.

STARTED means an attempt was begun. NEEDS_RECONCILIATION means someone must establish what happened. RECORDED means the queue effect was confirmed. None of these is a human approval state. Module 6 will show the entries changing one step at a time; for now, the essential rule is to inspect an existing attempt before starting another.

Use a clear decision order

For this small workflow, apply the following ordered checks. A record takes the first applicable disposition. More advanced services may use a different order, but it must be explicit and tested.

1. Validate request identity and revision. If they are unusable, stop with INVALID_INPUT in the run log. Use the run ID to track the error; do not invent a request ID.
2. Check the duplicate ledger. An already recorded identical request revision is DUPLICATE_SKIPPED. If the same identity and revision contain different material content, use HUMAN_REVIEW with reason identity_conflict and hold the existing operation for inspection rather than creating a second item. A matching key still marked STARTED or NEEDS_RECONCILIATION becomes TECHNICAL_HOLD; establish the existing outcome before any new write.
3. Check for attempted instruction bypass and material disagreement between structured fields and message. Route these to HUMAN_REVIEW. This is a teaching rule; real detection of malicious content cannot rely on a perfect keyword list.
4. If required values are missing, use NEEDS_INFO. If supplied values violate their type or range, use INVALID_INPUT. An unsupported item name is a policy exception rather than a malformed value.
5. Select the effective approved sources. Missing or unresolved conflicting sources produce HUMAN_REVIEW, without a guessed policy conclusion.
6. Guests, extensions, damage, unsupported items and above-limit durations produce HUMAN_REVIEW.
7. A complete valid standard request within the policy produces DRAFT_READY, after its proposed draft has passed validation.

A technical failure adds a separate operational state, TECHNICAL_HOLD. It blocks progression until an operator can establish a safe outcome. It is not a successful disposition and must not be hidden by a friendly draft.

Why filters must not overlap

Imagine a routing tool with two branches: staff requests go to the standard route, and duration above the limit goes to an exception route. A staff request for a six-day webcam matches both. Some workflow tools execute every matching branch. Route order alone does not make these conditions mutually exclusive.

Correct the standard condition to require all of the relevant checks: staff, new request, supported item, complete valid fields, no source conflict, no bypass or input conflict, within limit, valid draft and not already processed. Alternatively calculate one validated route value first, then branch on exact equality with that value. If the value is not recognised, a fallback branch holds the record for inspection.

DUPLICATE_SKIPPED is a log-only disposition that references the existing record; it must never create another review or hold item. TECHNICAL_HOLD pauses the existing operation without a second queue write. The beginner Make lab uses a previously checked route value to demonstrate routing. This is deliberately a small wiring exercise. The lab does not claim to automate every validation check or detect adversarial input. The complete route table remains part of the capstone design, and manual checks are declared as manual.

Worked review record

R102 is a staff request for a six-day webcam in October. Its duration exceeds P1.2's five-day maximum. A useful record contains:

Queue ID Q102; request R102 revision 1; draft version 1; configuration version 1; source P1 version 1; final_route HUMAN_REVIEW; reason above_standard_limit; draft “The requested six days exceeds the standard five-day webcam duration. A desk reviewer must decide whether an exception is possible.”; source_ref P1.2 and P1.5; review_state PENDING; reviewer unset; reviewed_at unset; next action inspect request and policy exception.

The record also contains a link or reference to the original synthetic input and the validation result. The reviewer should not have to reconstruct the reason from a mysterious status alone. For a missing-duration request, the reviewable artifact is a question draft rather than a policy decision.

Approval must bind to the content that was reviewed. If draft version 1 was approved and version 2 changes the duration, mark version 2 PENDING. A reusable “approved” checkbox unrelated to the current content can allow unreviewed changes through. In a real system, reviewer identity and permission come from the platform's authenticated controls, not an AI-generated text field.

Read the state diagram

The visual 03-review-state-machine.svg shows a validated draft entering PENDING, then a reviewer choosing revision, rejection or approval for a specific next step. An edit loops back to PENDING. No arrow leads directly from model output to sending or booking. A pause state holds unresolved technical outcomes.

Practice

1. Fill the route table for E001 through E009 using Pack A. Record the first applicable check and its evidence. Do not open the solutions yet.
2. Write filters for three branches based on exact final_route values: DRAFT_READY, NEEDS_INFO and a fallback. Explain where HUMAN_REVIEW and INVALID_INPUT land in this small lab and why the fallback cannot disappear silently.
3. Construct a full review record for R102. Add a focused review question, the exact source clause and the current draft version.
4. Apply Failure F-D. Reject the invalid assistant output before it reaches an ordinary review-ready path. A controlled correction can request the missing fields, but another invalid result must be held for a person.
5. Apply Failure F-E. Demonstrate what changes when the draft is edited after approval.
6. Optional: run the Make routing lab with three checked input records. Inspect which branch actually receives each. Otherwise perform the same branch trace in the workbook. Label your evidence accurately.

Expected artifact: a nine-case decision table, three branch conditions, a complete review record and two failure traces. Keep every route disposition visible, even when no outbound action occurs.

Check your understanding

M5 Q1. Why is putting the exception branch second insufficient if a request matches both branch conditions?

M5 Q2. What is the difference between DRAFT_READY and APPROVED_FOR_NEXT_STEP?

M5 Q3. A reviewer approved a draft, then an automated edit changes its duration. What must happen before the changed draft is used?

Before you continue

A reviewer should be able to understand a pending item without opening a model conversation. Next you will design how the workflow behaves when events repeat or steps fail.
