Ask a person to approve a consequential action, not every low-impact display step. A queue that treats each sentence as an approval will be ignored. A queue that hides the action until the evidence, the owner, and the priority are visible gives the review a job. The human-review article explains the states a reviewer can reach. This article is about how those states are operated as a queue: priority, ownership, completeness, aging, and escalation.
Illustrative queue design. A low-risk preparation step is not an auto-execution product.
Preparation is not execution
An agent can assemble a packet: the question, the governed result, the missing fields, and a draft note. That preparation can be low risk when it does not change a ledger, a work order, a filing, or a customer commitment. Calling that preparation “automatic execution” would overstate it. Orisdale does not publish an auto-execution product, and a model score is not permission to act.
The trust-layer article keeps the control outside the model. The queue is where a person uses that control. Consequential action stays blocked until the required review is recorded.
What a queue item needs
Each item should show enough to decide whether it can be reviewed now:
- Priority, from an approved rule, not from a model confidence number.
- An accountable owner, or a clear unassigned state.
- Evidence completeness: present, missing, or contradictory.
- Age, so an item cannot sit without a clock.
- The action that is blocked, stated in business language.
- The states the reviewer may choose: approve, reject, or request evidence.
Operations Intelligence already treats exception review, missing data, and review order as the point of the blueprint. A queue is that order made operational. It is still a blueprint when the page says so. It is not a claim that a customer queue is in production.
Priority without a fake threshold
If you need a numeric illustration, use the published Finance contract rather than a new pair of overlapping rules. In that contract, materiality is an absolute amount of at least 5,000 dollars or 10 percent, then management attention at 1,000 dollars or 5 percent, then within tolerance. The rules are ordered. They do not compete as two simultaneous OR gates with different stories. The proof explorer shows the three synthetic departments that fall out of those rules.
A material item can sit higher in a review queue than a within-tolerance item. That is a routing choice you must write down. It is not a claim that the within-tolerance item is correct, and it is not permission to skip it forever. Direction, over or under budget, does not replace the category. A model probability does not replace it either.
Missing evidence and escalation
Missing evidence should leave the main approval path and enter a request-evidence path. The owner might be the person who can supply the field, not the person who approves the action. Mixing those roles makes the queue look busy and unresolved.
Escalation is a coverage rule. If the owner is absent, or the item is older than the limit you set, name the next owner. Do not invent a measured backlog or a percentage of items that escalate. Decide the rule, then measure it after the queue exists. Until you have that measurement, do not publish a result.
Reject remains a real outcome. Request-evidence remains a real outcome. A design that only offers approve will train reviewers to approve.
Batching and fatigue
Batch items that share a definition, a period, and a reviewer. Do not batch items that hide a different action inside a repeated layout. A reviewer scanning twenty variance lines from the same contract can work. A reviewer scanning twenty lines that mix a filing, a payment, and a note will miss the one that moves money.
Show the blocked action on the item, not only in a manual. If the action is “no action, this is a briefing,” say that, so the reviewer does not think a click will post a journal entry. The executive briefing pattern is a reading surface. It is not the same control as an operations action.
What you can evaluate later
After a queue is in use, the useful measures are operational and modest. How old are unassigned items? How often does request-evidence return with the field still empty? Do rejected items reappear unchanged? You do not need a story about root cause to count those. A correct classification is not a cause. Observed contributors belong in the evidence, as hypotheses a person can accept or discard.
Limits
This design does not replace human review with a hotter loop, and it does not assign a safe percentage of work to unattended execution. Risk tiers can change how much preparation happens before review. They do not, on this website, authorize an agent to take the consequential step. Discuss the queue for one decision, including who owns it, from the contact page.
Operating rules that keep the queue small
Fatigue is usually a capacity problem disguised as a model problem. If every display of a number creates an approval, the reviewer learns to click through. Separate the surfaces. A briefing can be read without an approval click. A preparation step can assemble files. An action that changes a record, a payment, a filing, or a customer commitment waits.
Give each waiting item one owner. Shared ownership looks collaborative and produces silence. If the owner is a role rather than a named person, say which role, and say who covers that role when the calendar is empty. Aging starts when the item becomes reviewable, not when it was first drafted. An item that is missing evidence is not aging in the approval lane. It is aging in the evidence lane, with a different clock if you need one.
Priority should be explainable from the rule. In the Finance illustration, a material variance outranks a within-tolerance variance because the published contract says so, in that order. You can choose a different business rule. You should not choose two overlapping thresholds that both claim to be the material line. Reviewers cannot learn a queue that contradicts itself.
Escalation needs a destination. “Escalate” without a next owner is a label. Write the destination down: a named backup, a duty roster, or a decision to expire the item without action. Expiration without action is still an outcome and should be visible. It is not the same as approval.
Batching works when the contract is shared. A reviewer can accept or reject a set of within-tolerance lines from one period only if each line remains inspectable and the action on each line is the same kind of action. Do not batch a material exception into that set to save a click. The exception is the point of the higher priority.
What you measure later should be boring. Count unassigned items older than the limit you set. Count request-evidence loops that return empty. Count items rejected and resubmitted with the same payload. Those counts tell you whether the queue is operable. They do not tell you the root cause of a variance, and they are not available for Orisdale as published results because this queue is a design, not a running system.
The operations blueprint is the closest existing page: exception review comes forward, missing data stays missing, and the review order is part of the design. Use that page when the decision is operational. Use the Finance contract when the decision is a variance category. Do not merge them into one queue unless the owner and the action are actually the same.
A queue review on paper should take a few minutes and answer only operational questions. Who is allowed to see the item? What is blocked until they decide? What happens at the aging limit you chose? Which fields, if empty, move the item out of the approval lane? If those answers are missing, adding a model will not make the queue kinder. It will make the clicks faster. Keep the design small enough that a new reviewer can learn it from the item itself, without a separate legend for every icon.