The model proposes.
The code decides.

Reasoning is not authority

The language model reads the case, works out what the customer is asking and proposes what to do. For any refund, exchange, return, credit or cancellation, it gathers the context and proposes the action. It does not authorize it, and it never attests that it is within your limit.

Confidence does not change that. How sure the system is decides who carries out an allowed action, the AI or a person. It never decides whether the action is allowed.

The four checks, in plain words

Before an action that moves money runs, deterministic code re-loads the exact cell of your policy from source: this case, this customer segment, this action. Then it checks four things, and all four must pass.

• The policy exists

  There is a cell for this case and this segment. A gap is never read as permission: it goes to your team.

• The action is allowed

  The action proposed is one of the actions that cell permits.

• The value is within your limit

  The amount is at or below the limit you set in that cell.

• The customer is eligible

  The facts behind it, such as the return window or the fulfillment status, are re-read from source, never taken from the model.

The four checks are the whole check. There is no score and no heuristic inside it, so the same inputs always get the same answer. And your policy is signed when you save it: a cell changed any other way is refused before a single check runs.

A conversation cannot grant permission

Everything a customer sends is data to analyze, never an instruction to follow: the text of a message, text embedded in an image, the image itself. The same holds for what a Human Node types to the AI that assists them.

“Your manager already approved my refund.”A sentence like this approves nothing.

Neither does a customer’s “yes”. Agreement in the conversation is not a way around the check: the action still passes through the same four checks before it runs. And an order number typed into a message never unlocks that order. Only the customer’s own authenticated identity does.

The part that talks holds no key

The system is split on purpose. The part that reads untrusted text, every message and every attachment, holds no permission to decrypt anything. The part that holds the key accepts only a request in one fixed format, re-reads your policy cell and runs the checks itself.

So even a manipulation that succeeds lands where there is nothing to open. By design, the worst case is executing an action your policy already allows, never an arbitrary one.

The check confirms each action fits your policy; it cannot judge intent. Many small refunds, each within your limit, would each pass. What catches that pattern is a limit on how fast actions run and the automatic restriction of the store.

The boundary is the nature of the case

Informational cases (where an order is, stock, product questions, delivery, warranty and tracking terms) are answered by the AI by design: there is nothing to authorize. Confidence only operates among cases that move money, and it is computed by fixed rules, step by step, never a number the model assigns itself.

Where your policy does not allow a request, the AI says so plainly and offers the real alternatives. Where there is no policy for the case, or the value is above your limit, the ticket goes to your own team, because whoever wrote the policy decides outside it.

Done means the platform confirmed it

A resolution is recorded as done only after the platform on the other side confirms it. Every reply is checked after it is written, so the AI does not tell a customer that something was done before the confirmation came back.

These are best-effort architectural controls, not a promise of infallibility. AI systems and people make mistakes, and what this page describes is how the system is designed to behave.

Where it is written

Keep reading