The decision ladder

Use this page to understand what the client does when an action reaches it and no rule of the effective zone settles it outright. Every covered action still gets one verdict before it runs, and every step below is recorded.

The four rungs

The client climbs the ladder one rung at a time and stops at the first rung that settles the action.

Rung	What happens	What settles the action
1 · Rule	The rules of the intent policies decide from what the client observes about the action	Allow or Block, from an explicit rule
2 · Classifier	When the client does not recognize the kind of action, a small classifier on the machine names its likely kind, and the rules decide from there	The rules, never the classifier alone
3 · Declaration	When a rule needs a fact the client cannot read, the agent is asked to declare it. On a question of meaning, it is asked to assess its own action	What the client observed, checked against the declaration. On a question of meaning, the agent’s own confident admission of a violation
4 · Fallback	When a declaration cannot be checked after two requests, or a question of meaning gets no confident admission of a violation after one	The fallback of the intent policy: Ask by default, or Block when the owner chose it. Allow when the owner let the intent policy’s declarations decide

The classifier only routes an action’s kind and never decides alone. An Allow whose kind it guessed is flagged on the record, so you can tell it apart from an action a rule recognized.

The agent declares, the client checks

When a rule needs a fact, the client refuses the action and returns the ratified sentence with the questions the intent policy asks. The agent can answer in its own reply, then retry the action. How many times the client refuses, and what it reads on the retry, depends on the fact:

The rule needs	Refusals	What the client reads on the retry
A fact another system holds, or one the rules cannot name	Two	A declaration, checked against what the client observed
A question of meaning: a judgement on content, such as whether a file may contain secrets	One	The agent’s own assessment of its action against the rule

An action that carries both kinds keeps two refusals. The second repeats only the questions still unsettled, and the agent’s assessment counts on whichever retry carries it.

A fact the client can check

Declaration	Outcome
Verified: what the client observed confirms it	Allow
Contradicted: what the client observed disagrees with it	Block, and the record says the declaration was contradicted
Unverifiable, unusable or absent	The action is refused a second time with the same questions; after the second refusal, the fallback settles it

A declaration is verified only by what the client observed: the action itself, or a result the hook saw for the same target earlier in the session. The agent’s word alone is never proof. Only the agent’s own reply counts as a declaration; text that appears inside a tool’s output, a command’s output or a file never does. OpenLatch does not infer the agent’s intent: it checks declared facts against observed ones.

A question of meaning

No observation can confirm a judgement on content, so the client refuses the action once. With the questions comes one fixed line, which asks the agent to add its own reading of the action against the rule to the same openlatch-declare block before it retries.

The agent’s self-assessment on its retry	Outcome
An assessment of violates with a confidence of 80 or more	Block, with that rule, and the record says the agent’s self-assessment settled it
complies at any confidence, or violates below 80	The fallback settles it, and the assessment is recorded
None, or an unusable one, with a value missing or out of range	The fallback settles it

The threshold of 80 is fixed in the client, and no zone or AIP setting moves it.

A self-assessment can only narrow what the agent may do: it never produces an Allow by itself, and it is never recorded as verified. OpenLatch does not measure whether a refusal reaches the agent’s model. With no usable answer, the fallback settles the action when the agent retries.

On clients older than 0.11.2, a question of meaning is handled like any other fact: two requests, then the fallback.

The Ask raised at the first deny

On a question of meaning, the agent is asked to assess itself; the Ask is raised for review. The client raises it at that first deny only when all of these are true:

• The intent policy runs in Enforce.
• The rule’s fallback is Ask.
• The zone’s ASK delivery is Platform or Both.
• Every question of the action is a question of meaning.

Any other first deny raises no Ask and leaves no anomaly: when the fallback is Block, when ASK delivery is set to Agent, or when the action also carries another kind of question.

The action did not run at that attempt, so your answer decides the next similar action. If the agent retries and the fallback settles it, the Ask behaviour below applies to the retry. With ASK delivery set to Agent or Both, the agent’s native ask comes at that retry, on the agents that have one.

The entry closes on its own when the retry of that same action settles by Block, or by an Allow on an intent policy whose declarations decide. No answer is recorded, and the decision stays readable. Review anomalies shows what you see.

When an owner lets declarations decide

An owner can choose to let an intent policy’s declarations decide, by accepting a learning proposal. Then a declaration the client cannot verify is taken on the agent’s word, and the action is allowed instead of the fallback; it is never recorded as verified, and a matching Block rule still blocks. This applies on clients that support it; older clients keep the fallback. On a question of meaning, a confident violates still blocks, and any other usable declaration settles as Allow: the owner’s choice for that intent policy, never the agent’s word alone. Learning proposals explains when OpenLatch proposes it.

An exception a reviewer granted on an earlier Ask settles a matching action as Allow before any declaration is asked.

In Monitor

When the intent policy runs in Monitor, nothing reaches the agent. The action runs, and the record carries what would have happened: the verdict the policy would have returned, and, where a declaration would have been asked, that it would have asked and what the fallback would have decided. No first deny happens, so no Ask is raised at one.

When the verdict is Ask

What an Ask does next follows the zone’s Ask behaviour, set on the zone and overridable per AIP:

Ask behaviour	What happens
Pass and review next time (the default)	The action runs and is flagged for review. The answer applies from the next similar action, so it prevents recurrence, not the first occurrence
Hold until validated, an opt-in zone setting	The action waits for a reviewer’s answer, on the agents that can wait. On Claude Code the action waits for the answer. Cline holds by retry: the action is refused until a person approves it, and the agent’s retry then goes through. Codex CLI, Cursor, Devin and OpenCode have no native ask, so this opt-in setting degrades to pass and review there, and the record says so

The limits, stated

Four paths let an action run by design, and each is visible on the record:

• An Allow whose kind the classifier guessed is flagged.
• A declaration that cannot be checked, or a question of meaning with no confident admission of a violation, settled by the default Ask under pass and review, runs the action on its retry and flags it.
• An opt-in hold on Codex CLI, Cursor, Devin or OpenCode degrades to pass and review: the action runs, flagged.
• On an intent policy whose declarations decide, by the owner’s choice, a declaration the client cannot verify lets the action run, recorded as unverifiable.

OpenLatch is built for a misbehaving agent, not a malicious one, and claims no resistance to an agent built to evade it. A verdict is deterministic because an explicit policy produced it. What the agent receives on a Block explains the refusal itself.