nestonexStart a project Where should a person sit in an automated decision, and how do you stop the queue becoming the bottleneck?
Put a person where the cost of being wrong exceeds the cost of a review, and route only those cases to them. Confidence thresholds send the easy decisions straight through. The person needs to see what the system decided and why, and to override it without filing a ticket.
It means an automated decision is proposed, and a person confirms, corrects or rejects it before it takes effect. The automation removes the tedium; the person keeps the authority.
It is not a confession that the model is unreliable. It is the ordinary design for any system where an error has a cost somebody has to absorb: payouts, moderation, clinical or legal consequences, anything irreversible, anything visible to a customer under your name.
The alternative designs are a system that acts alone and is occasionally wrong in public, or a system that proposes everything and reviews everything, which is just the manual process with extra steps. Neither is what you want.
Review everything and the queue becomes the bottleneck the automation was supposed to remove. Review nothing and you have an unsupervised system. The design problem is the threshold between them.
Confidence is the usual lever, and it only works if the confidence figure means something — which needs checking against your evaluation set rather than trusting a number the model emitted. Above the line, act. Below it, queue.
Value is the better lever where money is involved. A small refund below a threshold can settle automatically; a large one goes to a person regardless of how confident anything is. Amount is a property you can reason about, and a stakeholder can set it without understanding the model.
Novelty is the third. Inputs unlike anything in the training or evaluation data deserve a person, whatever the confidence score claims, because confidence is least reliable exactly where the input is least familiar.
The reviewer needs the decision, the evidence behind it, and the action in one place. If checking a proposal means opening three other systems, the review becomes rubber-stamping — which is worse than no review, because it manufactures the appearance of oversight.
Override has to be one action, and it has to be recorded. Who approved what, when, and what they changed. That log is the audit trail, and it is also the training data for the next version of the threshold.
Queue depth is an operational metric, not a detail. If the queue grows faster than it drains, the threshold is wrong or the staffing is, and the system will fail by people approving in bulk to catch up.
And the reviewer's corrections should feed back. A queue where the same mistake is fixed a hundred times, and nothing changes upstream, is telling you something nobody is listening to.
It is not a substitute for limits. A person approving a transfer should not also be the only thing preventing a transfer a hundred times larger than any legitimate one. Hard caps are cheaper and more reliable than attention.
It is not a substitute for evaluation. A reviewer sees one case at a time and cannot detect a five percent drift in aggregate behaviour. That is what the evaluation set is for.
And it is not a liability transfer. Putting a name against an approval does not make an unreviewable proposal reviewable. If the interface does not give someone what they need to disagree, the approval is decorative.
Trade Rewards puts a person in front of the hot wallet. Rebates, referrals and game winnings accumulate in a single points ledger, and nothing leaves until an admin approves the withdrawal. Approved requests are then batched per chain and signed. The automation does the accounting; the release is a decision.
ProTrader's AI coach takes the other shape: rather than queuing output for review, it is constrained so that its output never needs one. It is given the member's own computed numbers, wrapped in guardrails that refuse trade recommendations, and capped on daily spend. Where you cannot bound the output, you review it. Where you can, bounding is better.
Only for the cases routed to it, which is the point of routing. A well-set threshold sends the large majority straight through and reserves attention for the decisions that warrant it. If everything is being reviewed, the threshold is wrong rather than the design.
Someone who would be accountable for the decision if a person had made it unaided, and who has enough context to disagree with the proposal. Reviewers without the authority or the information to reject something will approve everything, which converts oversight into paperwork.
Keep the queue drainable, put the evidence in front of them, make rejection as easy as approval, and track the approval rate. A reviewer approving ninety-nine percent of proposals is either looking at a very good system or not looking at all, and only sampling tells you which.
It can be tuned from the review record — cases consistently approved are candidates for automation, cases consistently corrected are candidates for a stricter gate. That tuning should be a deliberate, measured change against the evaluation set, not a drift nobody decided on.