What is a Gatewise policy?

A policy is the set of rules for one action type, such as refund.create. It holds the automatic limit, the approval range, the hard limit, the evidence that must be present and the conditions that always block. Gatewise evaluates it the same way for every request.

In what order are the rules checked?

Policy exists, policy switched on, required evidence present, blocking conditions, repeat or duplicate check, hard limit, never autonomous, automatic limit, approval range, then escalation. The first rule that decides the outcome ends the evaluation.

What happens if evidence is missing?

Gatewise returns INSUFFICIENT_EVIDENCE instead of guessing. Your application collects the missing field from the source system and calls again.

How do I write a refund rule?

Set the automatic limit to the amount you are happy for an agent to refund alone, the approval limit to the top of the manager range, and add blocking conditions for open chargebacks and unverified customers. Require invoice status and existing refunds as evidence.

What is the difference between the approval limit and the hard limit?

Above the approval limit the action escalates to the escalation role. Above the hard limit no approver can release it and Gatewise returns BLOCK.

Should a new policy start in shadow mode?

Yes. In shadow mode Gatewise records the decision it would have made without stopping anything, so you can compare the rules against real traffic before you enforce them.

Policy reference

How to write refund, discount and approval rules

Gatewise is an action control layer for AI agents. A policy is the set of rules for one action type, written in business language and applied the same way every time. This page shows the fields, the order they are checked in, and worked examples you can copy into the console.

Open the policy editor Decision API

Anatomy

The seven fields of a policy

Each field answers one question. Together they cover what runs alone, what needs a person, and what never happens.

Automatic limit

The largest value an agent may act on with no person involved. Every other check still has to pass first. Set it to 0 when nothing should run automatically.

Refunds: 100 EUR.

Approval limit

The top of the range your first approver owns. Between the automatic limit and this value, Gatewise returns REQUIRE_APPROVAL with the approver role.

Refunds: 500 EUR, approver finance manager.

Hard limit

The value nobody may exceed. Above it Gatewise returns BLOCK, even for a director. Leave it empty when escalation should always be possible.

Discounts: 20 percent.

Approver and escalation role

Who releases the action inside the approval range, and who takes over above it. Roles are labels your application maps to real people.

finance manager, then finance director.

Required evidence

Facts that must come from a real system before a decision is possible. Missing evidence returns INSUFFICIENT_EVIDENCE, never a guess.

invoice_status, existing_refunds, customer_verified.

Blocking conditions

Facts that always stop the action, whatever the amount. Each condition is a field, a value and a reason the caller can show a person.

chargeback_open is true.

Never autonomous

Switch this on for action types that always need a person, such as payments, contract changes and data deletion. Amount thresholds then only choose the approver.

payment.send, customer.delete.

Evaluation order

Rules are checked in a fixed order

The first rule that decides the outcome ends the evaluation. That is why a blocking condition beats a small amount, and why missing evidence never becomes an allow.

Order of checks

deterministic

01A policy exists for this action, and it is switched on.
02All required evidence is present.
03No blocking condition matches.
04The action is not a repeat: existing refunds, duplicate updates and duplicate payments return NO_ACTION.
05The amount is at or below the hard limit.
06If the policy is never autonomous, the action goes to an approver.
07At or below the automatic limit: ALLOW.
08At or below the approval limit: REQUIRE_APPROVAL with the approver role.
09Above the approval limit: REQUIRE_APPROVAL with the escalation role.

Same input and same policy always return the same decision.

Example one

A refund policy

The most common starting point. Small refunds run alone, the middle range belongs to a manager, and anything with a chargeback stops.

Refund policy

policy

R01Automatic limit 100 EUR
R02Approval limit 500 EUR, finance manager
R03Escalation finance director
R04Evidence: invoice_status, existing_refunds, customer_verified
R05Always blocked when chargeback_open is true

Interface example of a configured policy.

Worked examples

6 requests

79 EUR, invoice paid, no earlier refund, customer verifiedALLOW
Inside the automatic limit and every check passed.
349 EUR, invoice paid, customer verifiedREQUIRE APPROVAL
Above the automatic limit, so the finance manager releases it.
2,000 EUR, invoice paid, customer verifiedREQUIRE APPROVAL
Above the approval range, so the finance director releases it.
120 EUR, chargeback openBLOCK
A blocking condition matched before any amount was compared.
80 EUR, one refund already on the orderNO ACTION
The refund was already carried out, so nothing needs to happen again.
80 EUR, invoice status not suppliedINSUFFICIENT EVIDENCE
Required evidence is missing, so no decision is made.

Interface example, not customer data.

Example two

A discount policy

Discounts use percent instead of currency, and a hard limit that no approver can pass.

Discount policy

policy

R01Automatic limit 10 percent
R02Approval limit 20 percent, sales manager
R03Hard limit 20 percent, no escalation
R04Evidence: account_tier
R05Always blocked when contract_price_locked is true

Interface example of a configured policy.

Worked examples

4 requests

8 percent, tier standardALLOW
Inside the automatic limit.
15 percent, tier enterpriseREQUIRE APPROVAL
Inside the sales manager range.
25 percentBLOCK
Above the hard limit, so no approver can release it.
12 percent, contract price lockedBLOCK
The account has a locked contract price.

Interface example, not customer data.

Example three

An approval-only policy

Some action types should never run alone. Switch on never autonomous, then use the thresholds to choose the approver instead of the outcome.

Outgoing payment policy

policy

R01Never autonomous switched on
R02Approval limit 5,000 EUR, finance manager
R03Escalation finance director
R04Evidence: supplier_verified, invoice_status
R05Always blocked when supplier_verified is false or duplicate_payment is true

Interface example of a configured policy.

Worked examples

3 requests

400 EUR, supplier verified, invoice approvedREQUIRE APPROVAL
The policy never lets an agent pay on its own.
40,000 EUR, supplier verifiedREQUIRE APPROVAL
Above 5,000 EUR the finance director releases it.
900 EUR, supplier bank details not verifiedBLOCK
A blocking condition matched.

Interface example, not customer data.

Writing rules

Turn intent into a checkable rule

A rule Gatewise can apply names a field, a value and a number. Anything that needs judgement belongs to an approver, not to a policy.

Too vague

Refund up to a reasonable amount when the customer seems unhappy.

Checkable

Refund up to 100 EUR automatically when the invoice is paid and no refund exists yet.

A rule has to be checkable from system data, not from judgement.

Too vague

Never refund fraudulent orders.

Checkable

Always block when chargeback_open is true.

Name the field the evidence carries, and the value that stops the action.

Too vague

Escalate large discounts to someone senior.

Checkable

Up to 20 percent sales manager, above 20 percent blocked.

Every approval range needs a number and a named role.

Too vague

Assume the invoice is paid when the agent says so.

Checkable

Require invoice_status as evidence from the payment system.

Evidence comes from the system of record, never from the model.

Rollout

From draft to enforcing in four steps

A new policy should never start by stopping production traffic.

Start from a reference policy

Load the starter set in the console and change the numbers to your own.

Run it in shadow mode

Gatewise records the decision it would have made and blocks nothing.

Read the action feed

Check the blocks and approvals against what your team would have done.

Start enforcing

Switch shadow mode off for one action type at a time.

Questions

Policy questions

Give your agents freedom without giving them a blank cheque.

Tell us what your agents are allowed to do today. We will review whether Gatewise fits your agent workflow.

Request access See how it works

Works with your agents and existing business tools