Low-severity files keep landing in the complex queue and nobody can say why

The complaint is that simple files keep arriving in the complex queue. The real problem is that nobody can say why any individual file went where it went, and until that changes every proposed fix is a guess dressed as an opinion. So the first move is not to adjust a threshold. It is to produce, for one misrouted claim, the list of every rule that was evaluated, the field values each rule saw, the result of each comparison, and the one that fired.

Most claims operations cannot produce that. They can show the rule set and they can show the outcome, and the step in between is unrecorded. Treat that as the headline finding rather than as an obstacle to the investigation, because a routing layer without a decision log will drift again 6 months after you fix it, and nobody will be able to prove it drifted.

What one line of a routing decision log has to carry

The third row is the one teams cut to save storage and then regret. Claims enrich continuously — a policy lookup completes, a vehicle identification number is added, an adjuster attaches a schedule — so the record you inspect on Thursday is not the record the rules saw on Monday. Logging the values as seen, at the moment of evaluation, is the difference between a diagnosis and a plausible story.

5 reasons a correct-looking rule set routes wrongly

1. First-match ordering. The set is evaluated top to bottom and stops at the first hit, so a broad rule sitting above a narrow one silently swallows the narrow one's population. The narrow rule is never wrong; it is never reached.
2. Thresholds set for a book that has changed. A severity cut-off written when the average property loss was half its current size now promotes routine files into complex handling, and nothing in the system flags a threshold as stale.
3. A null field at evaluation time. The rule that should have fired could not evaluate, so the catch-all fired instead — and the catch-all is almost always the complex queue, because that is the safe default.
4. Overrides that never feed back. Adjusters quietly move files every day. Those moves are the highest-quality labels you will ever have about correct routing, and in most operations they are stored as a status change with no reason and no aggregation.
5. Overlapping queue definitions. Two queues are defined by criteria that both legitimately describe the same file — a low-value claim with an injury element, for instance — so the outcome is decided by evaluation order rather than by policy.

Ranked by how often the log actually implicates them, the null-field cause comes first and surprises people every time. It looks nothing like a bug: the file went to the queue the rules sent it to, the rules are all correct, and the reason is that a field the deciding rule needed was empty at 09:14 and populated at 09:33.

The catch-all is doing more of your routing than you think

Trace where nulls come from and you will find they cluster by channel and by reporter. A notice taken by phone from a third party has no policy attributes because the policy was never resolved — the failure path set out in when the policy lookup returns nothing for a covered loss. A notice started online and finished by phone arrives with whichever half of the form the claimant completed, which is the funnel problem in claimants starting the online loss report and phoning in anyway. In both cases routing runs against a partial record and the catch-all absorbs the difference.

• Distinguish 'false' from 'could not evaluate' in the log. They are different facts and merging them destroys the only evidence of this cause.
• Decide explicitly what a null means per rule. Sometimes absent means benign, sometimes it means unknown-and-therefore-escalate, and the correct answer differs by field.
• Consider a hold-and-re-evaluate window for enrichment that is genuinely in flight. Routing 15 minutes later on a complete record beats routing now on an empty one, provided the acknowledgement clock is not the thing you are spending.
• Measure the catch-all as a metric in its own right. If more than a small minority of files reach it, it is not a safety net, it is your primary routing rule.

A catch-all rule is a confession that the record was incomplete. Counting how often it fires tells you more about your intake than any report on queue volumes.

First match wins, and nobody has re-read the order

Rule sets accrete. A rule is added for a line of business, another for a carrier programme, another after an incident, each inserted wherever it seemed to fit that week. After 3 or 4 years the ordering encodes a priority scheme nobody chose. The decision log makes this visible in one query: sort by rule identifier, then count how often each rule was evaluated but never returned true, and how many were never evaluated at all. A rule with 0 evaluations in a quarter is either dead or shadowed by a broader rule above it, and both are worth knowing before you touch a threshold.

1. Count evaluations, fires and shadowing per rule over a full quarter. Shadowed means the rule would have fired had it been reached, which you can compute offline from the logged inputs.
2. Delete the dead ones before reordering. Reordering a set with dead rules in it changes behaviour in ways you cannot attribute afterwards.
3. Move from implicit ordering to explicit specificity, so the narrowest matching rule wins regardless of position. This removes an entire class of accident but must be done as one deliberate change, not incrementally.
4. Re-run last quarter's claims through the new set offline and diff the destinations. Any file whose queue changes is either a fix or a regression, and a person should look at every one before this goes live.
5. Version the rule set and log the version on every decision, so the next diff is a query rather than an archaeology project.

Adjuster overrides are the labels you already own

Every time an adjuster moves a file out of a queue, an expert has told you the routing was wrong. Capture the move with a short structured reason — wrong severity, wrong specialism, wrong locality, duplicate of another file — and aggregate weekly. If 1 reason code accounts for 30% or 40% of overrides, it names the rule to change, with better evidence than any workshop produces. Left uncaptured, that knowledge is re-learned by every new adjuster and never reaches the rules.

Overrides also surface queue definitions that genuinely overlap. The recurring example is a modest-value liability file that acquires an injury element and then medical documentation, which changes both who should handle it and what handling obligations attach to the file — territory covered in medical records sitting inside a liability claim. That is not a rule-ordering problem; it is 2 queues whose definitions both claim the same file, and it has to be resolved as a policy decision before any rule can express it.

What to do once the log tells you the answer

The order matters. Fix nulls first, because they contaminate every other measurement. Then delete dead rules, then resolve overlapping queue definitions with the people who own the queues, and only then touch thresholds — thresholds are the most tempting and the least often responsible. Whether any of this should be a model rather than a rule set is a separate argument with its own trade-offs, made in model scoring or written rules for claim triage; nothing on this page depends on which side you land.

Building the log itself is unglamorous and small: an evaluation trace, a table of narrow rows, an index on claim number and rule identifier, and a weekly report of fires, shadowing and overrides. It is the kind of instrumentation that makes everything downstream arguable with evidence, and it is a common starting point in AI agents and automation work because no scoring layer can be trusted on top of a routing layer nobody can explain. If you are evaluating someone to build it, explainability of the decision path is the question to press hardest on, which is the theme of choosing an AI development partner. The rest of the path from notice to queue sits in claims intake, FNOL and triage, inside our insurance and claims work.

• claims triage
• routing rules
• observability
• claims operations