Every system we ship has a human review queue. Partners sometimes read this as a hedge, as if the queue were there because the model is not good enough yet and will be removed once it is. It will not be removed. The queue is part of the design, and this note says why.
What the queue receives
Three kinds of item reach a reviewer.
The first is a field the machine is unsure of. Every extracted value carries a confidence figure. Below a threshold set in the SOW, the field goes to a person with the source region highlighted beside it. The reviewer sees the value, sees the document, and approves, corrects or escalates.
The second is a field that fails a rule. A quantity times a unit price that does not equal the line amount. A date of birth after the date of application. An invoice number that already exists. A rule can say that something is wrong without knowing what is right, and that judgement belongs to a person.
The third is a random sample. A fraction of items that passed every check still go to a person. This is how we learn about the errors the machine is confident about, which are the only errors that matter once a system is in production.
Why the queue is yours
The reviewer is the partner's employee, not ours. That is a deliberate choice and it follows from the three commitments we make to every partner: we never contact the BPO's client, the BPO sets the price, and everything we build transfers to the BPO.
A reviewer who works for the partner knows the client, the process and the exceptions that no specification captured. Their corrections are the most valuable data the system ever receives. Each one is written to the audit log with the reviewer's identity and fed to the next evaluation run, so the system improves in the direction the partner's own people push it.
It also means the partner can show their client a person's initials on every correction. That is a different conversation from "the vendor's AI handled it."
What the queue is not
It is not a place to hide a weak model. If the queue fills up, the accuracy floor in the SOW has been breached, and the operations retainer treats that as a Sev 2 incident: one process down or accuracy below the floor. The monthly report says how many items went to review, why, and what happened to them.
It is not unpaid work pushed onto the partner. The volume that reaches the queue is measured in the pilot, agreed in the SOW, and reported every month against the ceiling. When it moves, we find out why.
What changes over time
Thresholds move. As the evaluation set grows, the confidence threshold for a field can rise or fall with evidence behind it, and the random sample can shrink. Every change is gated on the evaluation set and recorded. What does not change is that a person can always see what the machine did and say no.
That is the property we are selling, under the partner's name. A yellow highlight means the machine read it. A red mark means a person touched it. Both are visible on every document that passes through.