Catching anomalies in logistics: rules, a model and a person in one flow

Logistics data is a tempting place to ask a language model, “anything odd in these records?” The records are messy, description fields are free text, and the exceptions keep changing. Ask the model that question directly, though, and you lose two things: consistency and control over cost.

The logistics anomaly flow we built with UiPath Maestro and agents splits the work three ways: rule-based RPA checks, classification with a language model, and automatic exception notification to operations stakeholders. This piece is about the reasoning behind that split.

How a shipment record moves through the flow

Rules, classification and notification are the backbone of the flow we delivered. The detail inside each step, and the human review gate, are the design I recommend for flows like this.

1. 01Data pull
2. 02Rule checks
3. 03Classification
4. 04Routing
5. 05Human review
6. 06Notify and audit

System

Data pull

Shipment records are pulled from the source systems at set intervals and brought into one format. Every later step works on that shared shape.

Rule

Rule checks

Deterministic checks run first: missing fields, thresholds exceeded, duplicate records and the like. There’s no point asking a model something a rule can answer with certainty.

Model

Classification

Records the rules flagged go to a language model together with their description and note fields. The model returns an anomaly type and a short rationale against a predefined schema.

Rule

Routing

The path splits on type and on the model’s confidence. Clear cases go straight to notification; uncertain ones go to human review.

Human

Human review

For uncertain cases an operations owner makes the call and records it with a reason. Those records are the best data you’ll get on where the model struggles.

System

Notify and audit

The right stakeholder is notified automatically, and the record, decision and rationale go to the audit trail. The same anomaly shouldn’t trigger a second message unless its status changes.

Previous Play Next 1 / 6

Don’t ask the model what a rule already knows

If a mandatory field on a shipment record is empty, you don’t need a language model to say so. Same if a defined threshold is exceeded or the same record arrives twice. These checks are cheap, give the same answer every time, and are easy to explain in an audit.

The model belongs where a rule can’t decide on its own. Free text is the clearest case, I think. The reason for a delay buried in an operations note, a phrase in a description field, what an inconsistency between two fields actually means: these are hard to capture with rules, and every new situation adds another rule. That’s where classification earns its place.

The ordering has a side benefit. The model only sees records the rules flagged, so cost grows with the number of suspicious records rather than the total.

Ask the model for a form, not an essay

Binding the model’s output to a predefined schema is what keeps the rest of the flow solid. The anomaly type should come from a fixed list, the rationale should be short, and there should be a field where the model can say it isn’t sure. A model that returns free text forces every later step to guess.

Writing the list of types with the operations team is part of the job. When something new shows up that isn’t on the list, a model that marks it as “other” is better than one that forces it into the wrong bucket.

Notification is design work too

Automatic notification can be the least discussed and most complained-about part of a flow. If everyone gets everything, soon nobody reads anything. When I design notifications I look at three things:

• Who receives it? The team or person responsible for that anomaly type.
• What do they see? The record, the anomaly type and a one-line rationale. Nobody should have to log in and search.
• When do they hear about it again? Not for the same anomaly, unless its status changes.

Where Maestro fits

Orchestration here means running the steps in the right order and making visible which stage a record is waiting in. Rule, model and human steps move at very different speeds: a rule finishes in milliseconds, a human review can take hours. UiPath splitting Maestro at FUSION 2026 into Orchestrate for long-running processes and Automate for short high-volume work recognises that difference at the product level. I went into it a little more in the first radar.

Put the human gate in from the start

The core of the flow we delivered is rules, classification and notification. If I built a similar flow again, I’d add a human review step for cases where the model isn’t sure from day one. My reason is simple: those records are the most valuable data you’ll get on which anomaly types trip the model up. When the human decision is recorded with a reason, the next improvement knows where to start.

Measure before you scale

Before rolling an anomaly flow out to a new region or a new data source, I’d measure three things:

1. Classification accuracy on a small labelled sample. Write it into acceptance testing.
2. The false-alarm rate. The operations team’s trust is won or lost in the first few weeks.
3. Cost per record. Model calls grow with volume; rule checks don’t.

If none of the three is measured, you have a promising demo. That’s all.