Start with the action, not a confidence score
List the actions your process can take: prepare a draft, update a record, send a message or submit an order. Decide which can proceed under an existing rule and which require a person. A model confidence score does not confer authority. A low-value change can still have serious consequences if it alters the wrong account. Include reversibility, affected people and the destination system alongside any monetary threshold. Have the business owner approve the policy in terms staff can explain.
Make thresholds unambiguous
Define whether an amount includes tax, which currency applies and whether related items are considered together. Use a hypothetical purchase request to test the boundary: what happens exactly at the threshold, just below it and just above it? Define rules for missing values rather than treating a blank as zero. Consider whether splitting one request into several smaller records would bypass the intended approval. The system should follow the business decision about related requests, not silently decide that each line is independent.
Show reviewers a complete decision
Present the proposed action, destination, reason, relevant source and any exception in one review view. The approver should see what will actually happen, not merely a summary such as "process this item." For a record update, show the current and proposed values. Keep source evidence available without overwhelming the reviewer with unrelated data. Name the person or role authorised to decide, and record their response. A notification that somebody opened is not the same as an approval they intentionally gave.
Bind approval to the reviewed version
A request may change while it waits. If the supplier, amount, destination or other material field changes, the old approval should not silently apply. Define which changes invalidate it and how long an unanswered request remains valid. For example, an approved draft with a later-added attachment may need another review depending on the process. Do not treat silence or an expired link as acceptance. Keep declined and expired requests visible with a reason so staff know whether to correct, resubmit or close them.
Test boundaries and absence
Test permitted actions, blocked actions, exact thresholds, missing information and an approver who is away. Check that a backup has the right authority rather than simply being copied into an email. Attempt to approve an older version and confirm it cannot execute a newer one. Inspect the destination system after each test: a successful approval screen is not proof that the intended write happened. Keep execution failures separate from approval decisions so the system does not repeatedly ask for permission to repair a technical problem.
Review the policy after real use
Track how many requests wait, how often reviewers reject them and which rules generate unnecessary manual work. Read actual cases before loosening a threshold. A high approval rate may mean the policy is sensible, or that reviewers are accepting items without enough context. Keep a change owner and re-test the boundaries after each policy update. Document why a rule changed so future staff understand its purpose. Approval design is complete only when the decision, authorised execution and final outcome can be connected.