Risk scores should not override policy.
A risk score is a reason to look closer. It is not a substitute for the explicit financial authority a person granted.The rule
Risk may make an eligible request more restrictive. It must never make an ineligible request less restrictive. That one-way relationship keeps probabilistic signals from weakening deliberate business policy.
Policy answers permission
A spending mandate contains explicit decisions: crypto is blocked, international requests are disallowed, the agent is limited to software and office equipment, or the monthly budget is exhausted. These are not statistical predictions. They express the authority a person chose to delegate.
If a Binance request has a risk score of 8, it is still declined when cryptocurrency is blocked. A low score cannot manufacture permission.
Risk answers scrutiny
An eligible request can still look unusual. It may involve a new merchant, an amount far above the agent’s normal pattern, rapid repeated requests, a category that does not match its purpose, or a country outside expected activity. Those signals are useful because policy cannot anticipate every operational pattern.
The safe response is escalation: return APPROVAL_REQUIRED and show the factors to a person. The reviewer can assess context without pretending the signal was a deterministic rule.
Opaque scores create false confidence
“Risk 46” is not self-explanatory. Operators need the band definition, triggered factors, source window, and limitations. Otherwise a precise-looking number can carry more authority than its evidence deserves.
Mandate’s MVP therefore returns a score together with named factors. It does not claim a calibrated fraud model or use synthetic statistics when a workspace has no transaction history.
A monotonic control model
Think of authorization as a one-way gate. Policy can approve, require review, or decline. Risk can leave an eligible request unchanged or move it toward more review. It cannot move a declined request toward approval. Human action can resolve a queued request, but it does not rewrite the original policy result.
This monotonic structure is easier to test and explain than a blended model where dozens of weighted signals can offset a hard business prohibition.
Design the interface around evidence
Show the exact policy rows first, the risk factors second, and the final outcome clearly. For queued requests, keep budget impact, merchant novelty, failed or review-triggering rules, and reviewer scope visible beside the action.
Read the authorization-decision reference for the three-state model.