Policy you can version, test, and roll back. Like code.
Your rules should not sit in application code, where changing one means a release. In Swiftward, policy is versioned: draft it, test it against real traffic, freeze it, and roll back by naming a version. No restart.
Versioning
Every policy moves through draft, candidate, frozen, archived. A frozen version is immutable, so the rules that made a decision last month are still there to read. Deploy a new version without restarting anything. If it does the wrong thing, point the deployment at any previous version, and that takes effect immediately.
Test before you enforce
Shadow mode runs a new policy against live traffic and records what it would have done, deciding nothing. A/B splits traffic between versions, so you compare outcomes on real events. Both answer the same question: what is this change doing to traffic arriving right now? What it would have done to traffic you already recorded is a backtest.
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 says which of the two decided. The engine runs the rules in two phases, so the verdict is decided before any side effect fires. Events for one entity process in order, and different entities run in parallel.
Stateful, which most engines are not
Track state across events: counters, counters over a time window, labels and metadata. Rate limits, velocity, reputation and cooldowns are built out of those. State is ACID and safe to re-process. A stateless engine leaves you to add a database and get event ordering right yourself. That is the difference between "is this request allowed" and "is this the fifth request this hour, and should the account now be held."
The rules are declared. So is everything around them.
The entities the engine reasons about, the screens a reviewer works in, the queues and their escalation paths, the roles and what each may touch, the fields that count as sensitive — all of it is declaration rather than code.
What that gives you, claim by claim, is on declarations.
In the request path, or in the background
The same engine runs two ways.
Synchronously, in the request path: a payment, an order or an agent's tool call waits for the verdict, and Swiftward returns allow, block or hold before it happens. Financial risk checks and AI agent calls need this path.
Asynchronously: events stream in — text, images, transactions — and each one is decided as it arrives, and the outcome follows: a block, an escalation, 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 takes the synchronous path because it is holding the connection. Both produce the same versioned record.