Letting a confidence threshold decide which documents a person actually reads
In document-heavy work the question is rarely whether a machine can read the document — it is which documents still need a person. Modeled as an orchestrated process, every document is classified and extracted, and a confidence threshold decides what a reviewer sees. The reviewer corrects fields rather than re-reading whole documents, and their corrections are what improves the threshold over time.
A reference architecture: how RoboAgentix would model this process on UiPath. It is not a description of a delivered project, and no client, result or metric is implied.
What starts it
A document arrives by mail, upload, scan, or a system that hands off a batch.
Why it is orchestrated rather than scripted
- Review capacity is the constraint, so the routing rule needs to be tuned without redeploying anything.
- Batches arrive unevenly, and the process has to survive a queue that is hours deep.
- What a reviewer corrects is evidence about the model, and it is only useful if it is captured against the instance.
How it runs on UiPath Maestro
The process is defined in BPMN and Maestro runs it across agents, robots and people, holding its state for as long as the work takes — including while it waits on an approver.
Step by step
- 01
Document arrivesSystem
By upload, scan, mailbox, or a batch handed over from another system.
- 02
Classify the documentAgent
The document type is identified and the extraction model for that type is selected.
- 03
Extract and validateAgent
Fields are extracted and checked for internal consistency, against reference data, and against the rules for that document type.
- 04
Above the threshold?Maestro
The orchestrator routes on per-field confidence and on which fields your policy never allows to pass unchecked.
- 05
Validate the fieldsPerson
The reviewer sees the document beside only the fields that fell short, corrects them, and the correction is kept.
- 06
File and hand offRobot
The validated record is written to the destination system and the document filed against it.
- 07
Reviewed and filedSystem
The document, its final values, and any correction are written to the audit record.
What each agent is allowed to decide
An agent is only useful in a governed process if its authority is written down. Each one below has a defined input, a decision it may make on its own, and the condition that obliges it to hand over.
Classification Agent
Decides what the document is before anything tries to read it.
Reads
- The document itself
- The taxonomy of types you process
- How similar documents were classified before
Decides on its own
Must escalate when
Extraction and Validation Agent
Pulls the fields out and checks whether they hold together.
Reads
- The classified document
- Reference data the fields must agree with
- Validation rules for that document type
Decides on its own
Must escalate when
What the robots do
Deterministic steps stay with robots — the same action every time, including in systems that never exposed a usable API.
Filing robot
Writes the validated record to the destination system and files the document against it.
Runs in
Above the threshold?
Every field at or above its own threshold, every cross-check passed, and no field present that policy always routes to a person.
- Passes
- Filed without review.
- Does not pass
- Sent for targeted validation of the failing fields only.
Modeled as a decision table, so the threshold can be changed by the people who own the policy without redeploying an automation.
The human step
Who
What they see
What they decide
People are in this process because judgment or authority belongs to them — not as a fallback for a step that failed.
What this design deliberately does not do
An automation is only trustworthy if its limits are written down as plainly as its capabilities.
- It does not add a type to the taxonomy on its own. A document it cannot place stops and waits for a person, rather than being filed under a general category so the queue keeps moving.
- It does not interpret the document beyond its fields. Whether a validated record amounts to an approval, a payment or an entitlement is decided in the destination system by whoever owns that decision.
- It does not move a threshold or swap an extraction model by itself. Corrections are captured as evidence for the people who tune the gate; changing a field's threshold is a release someone signs off on, not something an instance does mid-run.
- It does not alter the source document. Corrections are written to the extracted record, and the file as received stays exactly as it arrived so a later reader can check the values against it.
Failure has a defined path
Systems go down, confidence drops, approvers go on leave. Each of these is a modeled branch rather than a stuck instance.
- The classifier cannot place a document in the taxonomy, or places it in two types whose scores sit close together.
- Extraction does not run at all — running the wrong model would produce fields that look confident and are wrong. The instance goes to a person with the candidate types and the pages that support each. The type they pick is stored on the instance, and the extraction model for that type runs afterwards.
- The destination system of record or the document store is unavailable when the filing robot goes to write.
- The validated values stay held on the open instance and the write returns to the Orchestrator queue for retry. The document is not marked filed until the write comes back confirmed. If retries are exhausted the instance raises an operations task and stays open — it does not close as filed, and the reviewer's corrections are not lost with it.
- A document type starts returning fields below threshold in bulk — a changed layout, a new scanner, a degraded batch.
- Routing still happens document by document, so nothing is filed on weak values. But when the proportion of a type falling short moves against its own recent pattern, the batch is held before more validation tasks are created, and the document type is flagged for someone to look at the cause rather than absorbing it as review load.
- A validation task sits in Action Center and nobody opens it — the reviewer is away, or the queue has no active owner.
- The instance stays open and the task ages. It is reassigned along the delegation rule for that document type, first to the named delegate and then to the queue owner. It does not fall back to filing the agent's values, and it does not expire quietly; an unclaimed task keeps appearing on the aging list until a person with authority over that type acts on it.
Data, rollout, and what to watch
Data it touches
- The document is the sensitive object, and it is stored once. The instance carries a reference to it rather than a copy, and every step — classification, extraction, the reviewer's task, the filing robot — reads through that reference. There is no second copy of the page drifting out of step with the record.
- The store, the instance state and the extraction run stay inside the tenant and region the residency rule names. A document is not sent to a general-purpose service outside that boundary for reading or classification.
- Each agent sees the narrow slice its job needs. The classification agent gets the pages and the taxonomy. The extraction agent gets the classified document and the reference data its fields must agree with — not the wider customer or case record in the destination system. The reviewer sees the whole page, because a field can only be judged against the context it sits in.
- Fields the policy marks sensitive — identity numbers, account numbers, clinical or case codes — can be masked in the task view and in the log while still passing to the filing robot, so the value reaches the system of record without being displayed to everyone who touches the instance. Retention is set per document type, and the record of which fields were changed and by whom can be kept after the document itself is destroyed.
How it goes live
- 01
Shadow
Every document is classified and extracted, and every document still goes to a reviewer exactly as it does today. The agent's values are recorded beside the reviewer's but never used. This phase is what sets the thresholds: fields where the two already agree are candidates for passing unattended, fields where they disagree are not. The gate to the next phase is a threshold agreed per field per document type, approved by the person who owns that type.
- 02
Supervised
The gate is live and routes, but every document still reaches a reviewer, who now sees which fields the gate would have let through and can disagree with it. Disagreements are the signal that a threshold is wrong. The gate to the next phase is a decision by the document type's owner, taken per type: they stop finding fields the gate passed and a reviewer had to correct.
- 03
Unattended with exceptions
Documents clearing the gate file without review; only the failing fields reach a person. It is turned on one document type at a time, and a new type enters at shadow rather than inheriting the thresholds of a type it resembles. Because the gate is a DMN table, a threshold can be raised or a whole type sent back to supervised without redeploying the process.
Signals worth watching
- The share of documents that reach a person, tracked per document type rather than across the whole queue — a single type drifting upward is a layout or source change, and it hides inside a total.
- Fields the gate passed that turn out to be wrong, whether a reviewer catches them on a later document or the destination system rejects them. These are the errors the threshold did not stop, and they matter more than the ones it held.
- Documents the classifier could not place, and how often a genuinely new layout is behind them rather than a bad scan — it is the earliest sign the taxonomy is out of date.
- How long validation tasks wait before someone opens them, and the age of the oldest instance still open, broken out by reviewer group. A queue that is deep and a queue that is stalled look the same on a count.
Named without target values. What good looks like depends on your volumes and your risk appetite, and is set with you rather than asserted here.
The UiPath components this design uses
UiPath Maestro
Runs the BPMN process and holds its state for as long as the work takes, including while it waits on a person or a system that is down.
UiPath Agent Builder
Where each agent is defined — its instructions, its tools, its inputs and outputs, and the escalation that sends work to a person.
UiPath Document Understanding
Classification and field extraction, returning a confidence score per field that the policy gate can route on.
UiPath Action Center
Where a human step actually lands. The approver gets a task with the agent's reasoning and sources attached, and the process resumes on their decision.
UiPath Orchestrator
Schedules the robots, holds queues and retries, and issues the least-privilege credentials each automation runs under.
Systems it touches
- Document store or content management
- The destination system of record
- Reference data the fields validate against
What the run leaves behind
- The document as received and the type it was classified as
- Every extracted value with the confidence behind it
- Which fields a person changed, from what to what, and who changed them
- Where the final record was written
Other representative workflows
Talk to us about a process like this.
The most useful first conversation is about a real process — where it stalls, who approves what, and which systems it touches.