Beyond Allow and Deny: The Case for PROOF, VIOLATION, and UNDEFINED

When Policy Cannot Decide

English · 本站阅读。方法定义见 AI Execution Boundaries。

1. Binary Exits Hide What Policy Cannot Decide

In many enterprises, Policy Evaluation is compressed into two results: Allow or Deny. It looks simple. An agent proposes an Action. Policy Evaluation says Allow, or Deny.

The door can be binary. A request either passes or it is blocked. Authorization and Validation stop at the door. This article is about what happens after a request has entered business Policy Evaluation — and why that evaluation cannot be compressed into Allow or Deny.

Once Policy Evaluation has only two exits, it usually assumes one thing: the system can give a definite reading of the business facts and of the rules in force. One or the other.

Inside a real business system, a third kind of case appears. The rules have proven neither that this Action may proceed, nor that it violates a policy in force. The current business state may be missing. Related facts may not have synced. The case may not be covered. A condition may be impossible to determine right now.

If the only exits are Allow and Deny, "cannot decide" will be disguised as one of them.

Treat it as Allow, and the system may change business state with no basis.

Treat it as Deny, and "the policy forbids this" is mixed with "the system cannot tell."

Neither is accurate. Afterwards it looks as if the case was already governed. What you actually have is a fake decision: a silent allow, or a silent deny.

The problem is not a more elaborate set of Allow/Deny rules. Policy Evaluation must be allowed to say, clearly: it cannot decide right now. Policy Evaluation is not a binary function.

2. Why PROOF, Not Allow

Once a third exit is allowed, the output of Policy Evaluation can no longer be called Allow or Deny. The three Canonical Evaluation States are PROOF, VIOLATION, and UNDEFINED. These three are what the AI Execution Boundary must be able to return at the evaluation layer. Start with PROOF.

Allow is too loose. It can mean "open by default; nothing stopped it." At a serious execution boundary, that kind of Allow is not used. PROOF is.

PROOF means: given the current business facts and the policies in force, the action is proven to be explicitly allowed, and the conditions are met. The action is allowed because those conditions are met. Not because no rule blocked it. PROOF is a Canonical Evaluation State. It is not a default policy.

"No rule intercepted it" is not the same as "it is proven allowed." If an Action is executed only because none of the rules happened to trigger, that is not permission, and it is not PROOF. "Nothing blocked it" is not PROOF. A strict policy environment may produce relatively few PROOF results. That is not a defect.

3. VIOLATION Is a Proven Breach

The opposite of PROOF is not a generic Deny. It is VIOLATION.

VIOLATION means: the action is proven to violate a policy in force. An explicit policy clause exists. The current business facts line up with it. And this Action has been shown to break that clause.

The result is not only a refusal. It has to be possible to say which Policy was broken, and by which facts. That belongs to Evidence. It is not a new kind of record.

Take a refund. The order is already completed, and a refund is still requested. The rule is clear. That is VIOLATION, and the action should be blocked. It is not the same case as "we do not know whether this refund should proceed."

The door is still a different layer. An expired token, a malformed payload, a failed schema check, a caller with no permission: these matter, but the request has not reached Policy Evaluation. They are not a fourth evaluation state, and they are not a kind of VIOLATION. This only confirms the line already drawn. Authorization and Validation stop at the door. VIOLATION is produced only after the request has entered Policy Evaluation, and only when the action itself is proven to violate policy.

Who may call, and whether the current business state allows the action, do not belong in the same box.

4. UNDEFINED Must Be Explicit

Most governance discussions assume a world of allow and deny. In real enterprises, a large share of cases is this third kind: the rules do not cover the case, or it cannot be computed right now.

UNDEFINED is not a decision. It is a lack of decidability.

For a business owner, "no applicable rule" and "cannot be computed" are often the same thing: the action cannot be proven allowed right now. Both are therefore returned as UNDEFINED. The causes underneath can still be distinguished — insufficient information, insufficient coverage, current facts unavailable, no applicable Policy, an evaluation error, a timeout — but the output is still one Canonical Evaluation State. There is no fourth state.

What to do with UNDEFINED cannot be decided by the Policy that is already under evaluation. That Policy already failed to cover the case. It is decided by a separate Default / Fallback Handling Policy: route it to a human, deny it, or allow it under conditions, according to risk. The danger is not that UNDEFINED exists. The danger is a silent allow or a silent deny when the system hits it, with nobody knowing afterwards.

UNDEFINED makes coverage and context gaps visible. Policy coverage gaps are governance gaps.

5. Human Review Is Not a Fourth State

On site, HITL — Human-in-the-Loop — is easily treated as another evaluation state. It is not.

There are two different kinds of waiting for a human.

The first: Policy explicitly requires approval. A refund above $5,000 must be approved by a human. That is PROOF, plus an Obligation. The Policy Decision Point (PDP) makes the decision. The Policy Enforcement Point (PEP) fulfills the obligation. This is already a decision. It is not "we still do not know."

The second: Policy cannot decide, and the fallback handling policy hands the action to a person. That is the handling of UNDEFINED. The person is providing a decision the rules could not make. They are not carrying out a permission that has already been proven.

Both look like waiting for a human. Their audit meaning is different. Mix them, and a later review cannot tell whether the rule required a signature, or whether the rule never covered the case.

Human review required by Policy is still a decision. Human review because Policy could not decide is not.

6. Once the Three States Are Explicit, the Gap Can Be Seen

When Policy Evaluation moves from two results to three, the value is not only defense. It is visibility.

Under a binary system, the dashboard usually shows only allow and deny. You cannot tell which denials proved that this Action violated policy (VIOLATION). You cannot tell which denials mean a new action has no rule yet, and the system does not know what to do (UNDEFINED). Allow and Deny hide the gap inside "already denied" or "already allowed." The three states mark the gap as UNDEFINED.

Once the three states are in place, a real governance metric can appear: of the actions that actually reach Policy Evaluation, how many can the policies in force decide explicitly — that is the Policy Decidability Rate. The previous article already gave the definition. This article will not expand the formula. Without three states, the metric stays muddy.

7. What This Article Pins Down

This article pins down one thing: Policy Evaluation is not a binary function. Evaluation must be able to return PROOF, VIOLATION, or an explicit UNDEFINED. These three states are the output of the AI Execution Boundary at the evaluation layer.

• PROOF: the action is proven allowed.
• VIOLATION: the action is proven to violate policy.
• UNDEFINED: the system cannot decide right now.

The test is simple. Take one production Action — already running, or already built but held back from automated writing. Give it to the rules you already have, at the Policy Evaluation layer. See whether you get a vague Allow or Deny, or one of the three results above, in a form you can defend.

The next step is not a longer methodology. The next step is to see these three outputs on a live system, instead of disguising "cannot decide" as a decision already made.

A vague Allow or Deny is not a decision you can defend.

The formal definition of the methodology is on the AI Execution Boundaries method page. The previous articles are When AI Can Act and the series index on Insights.