An approve button is not human oversight

A reviewer sees a card: "Approve refund of £480?" There is a yes and a no. They handle roughly two hundred of these a day, and the approval rate sits at 99.6 per cent.

That is a latency tax with a signature attached, and in an audit it will be worth exactly nothing.

What a reviewer actually needs

An approval payload is an interface between a machine's reasoning and a human's judgement, so it has to carry the reasoning. Five things, and the reviewer should not have to open another tab for any of them.

The claim, plainly stated. The evidence the system used, with links to the source records rather than a summary of them. What changed since the last similar decision, because reviewers spot anomalies far better than they audit absolutes. The blast radius if this is wrong. And the rollback path, named, so that approving feels reversible when it is and appropriately heavy when it is not.

Then design the default. Every queue eventually backs up, so decide now what happens to an item nobody touches in four hours. Auto-approve, auto-reject and hold indefinitely are all defensible; discovering your default by accident during an incident is not. Also track disagreement rate rather than approval rate. A queue where humans never say no is a queue you can delete.

Boundaries travel with the event, not with the request

The moment AI work moves off the request path into queues, which it should for anything slow, retryable or expensive, ambient context disappears. There is no session, no request-scoped tenant, no authenticated user sitting conveniently in a thread local. A worker picks up a job and knows only what the message tells it.

So the message has to carry identity: which tenant, on whose authority, with what permissions, valid until when. Rehydrating that from a user ID is where cross-tenant leaks are born, because the lookup happens in a code path nobody wrote tests for. The tenant boundary belongs on the architecture diagram as a line the event crosses with its credentials. Leaving it to a WHERE clause means trusting everyone to remember it.

Durable queues buy you real things: retries without duplicate side effects if your handlers are idempotent, backpressure when the provider is slow, and an ordered record of what the system did. That record is also your support tool. When a customer asks why an automation recommended something, the answer should be a lookup by correlation ID that returns the trigger, the evidence, the model version and the approver. If support has to ask an engineer, your escalation path was improvised.

Approvals, events and tenancy are the same discipline: make the boundary explicit, and put the evidence where the human already is.

Open your approval queue and look at last month's disagreement rate: if it is close to zero, is the human catching anything, or just absorbing the liability?