A permission slip, filled in by the model, asking to refund order 4417 for forty dollars, with the signature line still blank: the model can only ask. Below it, the cast of this storyboard: the Gate permits, the Tool writes, and the Record keeps the balance. A model can ask for an action. Something else decides whether that ask becomes a real effect, and then whether it actually worked.
One: check the request. Is it a real operation, with the right types, referring to things that exist? Two: decide whether it is permitted, for this caller, in this context, right now. Three: run it, with whatever limits apply. Four: check what happened. Not whether it returned, but whether it is true. It is a sequence, not an architecture.
A request can be valid but not allowed, and get stamped denied. It can be allowed but fail to run, when the tool errors or times out. Or it can run, return 200 OK, and change nothing, which is the most confident failure of all.
The Model asks for its refund and the Gate replies: lovely, and may it run, for you, here, now? Four things get mistaken for permission. Being logged in tells you who is asking, not what they may do. Being well-formed: so is a request to delete production. Being 97 percent sure is a mood, not a permit. A human saying yes is a way to answer the question, not the question itself. A rule in a prompt is a request; a rule at the gate is a check.
A yes-or-no switch either blocks the useful or waves the rest through. Four answers work better. Allow, when it is permitted and the evidence holds, leaves a receipt. Ask, when a person should decide, leaves a question and the reason. Deny, when it is not permitted or too risky, leaves a reason code. Defer, when evidence is thin and the stakes are high, leaves a handoff note. What moves the needle most is how hard the action is to undo: the bar for allowing it rises from a one-click undo to an apology email.
When the Gate hands a decision to a person, a note saying “can you take a look?” is no help: look at what, exactly? A useful handoff reads: refund forty dollars to account 88, over the twenty-five dollar auto-limit, order 4417 marked delivered, approve or decline? A specific question, with the reason. Who reviews it, what they see, and whether they can say no is its own design problem.
The Tool holds up a 200 OK receipt and says it is all done. The Record shows the balance was 120 dollars and is still 120 dollars. A step that reports done is not a step that shows done. A 200 tells you what the interface said. If what you wanted was a change of state, go and read the state.
One bin labelled “it broke” turns incident review into storytelling. Sort failures instead. Policy denied it: was the rule right? The tool errored: fix it, or retry it. Verification failed: the tool fibbed, or you checked the wrong thing. Evidence was missing: go and get it. Over time or budget: raise the limit, or don't. You can't sort a failure at a boundary you never made explicit.
The Model still varies: forty dollars this time, perhaps forty-one the next. The Gate applies the same rules, and the Record shows the same answer every time. The checks don't make the model deterministic. They give you a dependable answer about one candidate action: permitted or not, every time.