One engine for every decision: stateful, and deterministic where it matters.
The engine reads each event, the state it keeps for each entity, and the signals your rules ask for, and returns a verdict. It runs in the request path or in the background, and a new policy version goes live without a restart.
Versions you can test and roll back
Every policy is versioned, and a frozen version cannot be changed, so the rules behind last month's decisions are still there to read. You roll back by naming an earlier version, and the change takes effect immediately.
Before you promote a new version, you test it three ways:
- a backtest over traffic you already recorded;
- shadow on live traffic, where it decides nothing;
- an A/B split, where it decides for a share of traffic.
How each one works is on safe change.
Deterministic where it matters
A rule built from deterministic checks gives the same verdict on the same inputs, every time. You decide which rules stay deterministic and which ones ask for judgment instead: a rule can call a model, or open a case for a person, and the record shows what decided. The verdict is decided before any side effect runs. Events for one entity are processed in order, and different entities run in parallel.
Stateful, which most engines are not
The engine keeps state for each entity across events, so a rule can ask "is this the fifth request this hour, and should the account now be held?" Counters, counters over a time window, labels and metadata give you rate limits, velocity checks, reputation and cooldowns. State changes are ACID, and an event that arrives twice changes the state only once. A stateless engine leaves you to add a database and get event ordering right yourself.
The rules are declared. So is everything around them.
The entities, the review screens and queues, the roles and the sensitive fields are declaration rather than code, like the rules. What that gives you is on declarations.
In the request path, or in the background
Synchronously, in the request path: a payment, an order or an agent's tool call waits for the verdict, and Swiftward returns approved, rejected or flagged before it happens.
Asynchronously: events arrive in a stream — text, images, transactions — and each one is decided as it arrives. The outcome follows: a block, a case for a person, or an action in another system. That is how moderation runs at volume without making the user wait.
The caller chooses per call, and a gateway always waits for the verdict. Both paths write the same decision record, naming the policy version that decided.