Nearly every permission system in production is binary. The agent can do the thing, or it cannot. This is a modelling error, and it is the one that most reliably makes governance useless to the people who need it.

Consider three actions that all render as "no":

• Pay a supplier invoice. The finance agent is certified to depth 3, and moving money is depth 4. One step short, and a named person can clear it.
• Quote a price. The agent cannot, because no pricing source is connected. Nobody decided this. The chain said no on this occasion, and named the bound.
• Reverse a settled transfer. The agent cannot, because a settled transfer is gone on the rail it went out on. Someone decided this, and no permission grants it.

In a binary system these are the same cell in the same table. In practice they demand three different responses. The first is a decision for a person. The second is a to-do — connect the source and it resolves. The third is a fact about the world, and treating it as a to-do sends someone off to hunt for a setting that does not exist.

Four outcomes

Allowed. The capability exists, every bound permits it, and it runs at the depth shown. Uneventful, and most of them.

Held. One step short. The action is real, the agent is one depth below what it needs, and a named person decides — with the reason attached, and nothing done until they have.

Refused. The chain said no on this occasion: a bound two or more steps short of the action, a guardrail at zero, or money moving above the working ceiling, where the agent may only draft. Filed on the ledger with the bound that refused it, and nobody is asked to approve it. Every refusal in our Governance view names the bound that produced it, and what would have to change.

Withheld. A platform floor. It exists, it works, and it is refused on purpose — not mounted at any depth, in any tenant, and no plan or approver reaches it. Granting it is not a settings change; it requires the reason it was withheld to stop being true.

What it changes downstream

Once the outcomes are distinct, several things become expressible that were not before.

A "no" can carry the right tone. "One step short — held for the finance lead" invites a decision. "No pricing source is connected — 41 refusals last month" invites action. "Reversal withheld at the platform floor; what I can do is raise a return request" closes the question and offers the real path. An agent that says all three with the same flat "I am not able to do that" has told you nothing each time.

A roadmap falls out for free. The list of refusals, sorted by how often each bound produced one, is the highest-signal backlog for your knowledge base that exists anywhere in the product. It is derived entirely from what your agents actually could not answer.

A queue falls out too. Only held actions reach a person, so Human review carries the decisions a person can actually make, and nothing that was never theirs to make.

And an audit becomes possible. When someone asks why the agent did not do the obvious thing in March, "held", "refused" and "withheld" produce different investigations. One is a question for the person who answered. One is a wiring bug, or a certificate that had not earned it. One is a policy conversation.

The cost

Four outcomes are harder to explain than two, and every surface that displays capability has to carry the distinction or it leaks. We spent longer on this than on anything else in the interface, and we still get asked why "held" and "refused" are not the same chip.

The answer is that they are the same chip right up until the moment someone needs to act on one, and then they are not.