What does a real intake case look like when the first routing decision turns out wrong?

A broker at Aster Financial uploads home loan application `APP-2187` on a Monday morning. The intake officer sees that the payslip attachment is present but covers a single pay period, and the declared household income does not match the employment letter. The record moves from `received` to `incomplete`, and a request-for-information task, `RFI-0931`, goes to the broker listing the two gaps.

The broker replies with a second payslip but not the letter. The intake officer judges the file sufficient for initial assessment, marks the letter as `waived_pending`, and routes `APP-2187` to the standard assessment queue instead of the specialist self-employed queue. Later, the assessor reopens the case because the letter was needed after all. The case returns to intake with a handover note and an `intake_rework` flag.

**Consequence:** the application sat in the wrong queue, and the reopen is logged against the original routing decision, with its reason code.

**What it teaches:** a routing agent needs the incomplete status, the partial reply, the waiver, the judgement call and the later reversal, all linked to one case. When you describe this kind of line in a catalogue, say that it carries linked event histories and a reason code on each decision, and confirm that against a sample before you list it. Because the data is generated, your customers will also want to know how grounding and disclosure risk were inspected.