Maker-Checker on Every Move That Matters (Part 2 of 4)
Sensitive actions don't just execute — they hold, until a second person approves. And the approver can never be the person who asked.
Trust, Metered — Part 2 of 4. (Start at Part 1.)
Maker-checker on every move that matters
On this platform, a sensitive action — certifying something, dispatching a settlement — doesn't just run when you click it. It holds. It goes into an approvals queue and waits for a second person to look at it, see the reason, and say yes or no. Only then does it execute. We call it hold-then-execute, and it's the difference between "the system did a thing" and "two accountable people agreed the system should do a thing."
The important part is the rule underneath: the approver can never be the maker. Separation of duties isn't a policy in a handbook here — it's enforced. Even when a whole tenant shares a single operational token, the platform keys each action to the individual who took it, so it can tell the requester and the approver apart and refuse to let them be the same human. (That last bit was a real fix we shipped — a shared token was quietly collapsing two people into one identity, and maker-checker means nothing if the checker can be the maker wearing a hat.)
Around the queue sits the boring, essential furniture: KPIs so a backlog is visible, reasons captured on every approve and reject, and a per-user notifications centre so the right person actually knows something is waiting on them.
Why build this into the rails instead of trusting process? Because on money infrastructure, "we have a policy that two people should check large disbursements" is worth exactly as much as your least careful afternoon. "The system will not execute this until a different person approves it" is worth the same on your worst one.
Honest note: friction is the point, and friction is annoying. Every held action is someone waiting. The craft is putting the gate only on the moves that genuinely matter — certify, dispatch, the things you'd want a second signature on anyway — and letting everything else flow, so the queue stays meaningful instead of becoming noise people rubber-stamp.
Holding the risky moves is control at runtime. But the deepest governance happens earlier — before a single line of code is written.