A code-side risk tier sends the €512.64 refund to a human approval queue

Follow the MEDIUM branch and you can start pricing the design. `propose()` runs `RiskPolicy.tierFor(action)`, builds a `PendingApproval` from a random UUID, the action, the tier, the description and the current timestamp, pushes it onto a queue, writes an audit line carrying the action, the tier and the queue id, and returns an outcome of `QUEUED_FOR_APPROVAL` with the message "Awaiting human approval" ^[12].

That record has five fields. It has no assignee, no expiry, and no marker showing the request was already approved ^[20]. That gap is exactly where the author's own list lands: which human, how long does it stay valid, can the same request be approved twice ^[18]. He asks nine such questions ^[19], and the text supplied breaks off mid-sentence as he begins to say what they added up to ^[23]. The queue itself is one interface call in the snippet, but the durable system behind that call is the part that needs an on-call rotation.

The classification granularity is the other thing worth reading closely. The tier function takes the action, and `propose()` is called with `ActionType.DELETE_DATA` plus a separate free-text description ^[15]. So the key is the verb ^[21]. REFUND would be a tier; €512.64 is a description ^[2]. If your risk actually lives in the arguments (amount, account age), then `tierFor` needs those arguments, and the rule that refuses an unclassified action before the switch runs ^[11] has to hold over a much larger input domain than an enum. This is the condition under which the approach transfers. A small, enumerable action space makes exhaustive classification a morning's work. A parameterised one turns it into a policy engine.

"No default" is also a short phrase that means every new tool ships with a policy edit attached, which is the sort of friction that gets quietly removed at 4pm on a Friday.

The VERY_HIGH case is the best engineering in the piece. The service has no execution path for those actions, so the claim is checkable by reading the class rather than by trusting a flag ^[8], which is the author's distinction between a prompt instruction and an architectural property ^[9]. The limit is what the assertion covers. It reads the outcome enum the gate returns; it does not establish that no other class holds a reference to the effectful client ^[22]. The author says the enforcement point is one method ^[10], and that property holds only while it is the one method that can reach the API. That is a fact about the import graph, not about the switch.

Model confidence never enters the control flow, which is the stated point of choosing tiers in code over prompt constraints ^[5]. Separating deciding from doing ^[3] is cheap to say and cheap to enforce in a single switch. The bill arrives in the queue behind it, and that bill is identical whether the model was right or wrong.