A stop the system cannot talk its way past
This is the decision the whole product is arranged around: when work is about to do something consequential — leave your machine, spend money, change something that cannot be easily undone — it stops and hands the decision to a person.
The hard part is not the idea. It is making the stop real.
Our first attempt was, in hindsight, a checkbox. The consequential action carried a flag that meant "a human released this", and the system trusted the flag. The trouble is that a flag the requesting side can set is not a stop at all — it is a formality the agent can satisfy by itself. It looked like a gate and enforced nothing. We shipped it, reviewed it hard, and it did not survive the review. That is exactly the kind of thing this log is for.
What replaced it is a hold the server owns end to end. When a consequential action reaches the stop, the server issues a single-use challenge, tied to that exact action, and times it against its own clock. The action can only settle by presenting that specific challenge back, unspent, after the hold has actually elapsed. The requesting side cannot mint it, cannot reuse it, and cannot fast-forward the clock. A reversible action never hits any of this and just proceeds; the friction is spent only where it earns its place.
When the stop triggers, what a person gets is not a yes/no popup. It is a prepared card — where the action goes, what it costs, whether it is reversible, how fresh the evidence is, and the exact passage it is standing on — with the deciding held back until they act. The screen above is a prototype fixture; the numbers in it are placeholder.
Two independent review passes went into getting this right, and both caught real defects — including the forgeable first version and a bug where an invalid approval was recorded before it was rejected. We would rather write that down than quietly fix it. The stop is the product; it has to be honest all the way down.