Policy you can version, test, and roll back. Like code.
Your rules should not live buried in application code, edited by a deploy and a prayer. In Swiftward, policy is a versioned artifact: draft it, test it against real traffic, freeze it, and roll it back in one click. No restart.
Versioning
Every policy moves through a lifecycle: draft, candidate, frozen, archived. A frozen version is immutable, so the rules that made a decision last month are still exactly there to inspect. Deploy a new version without restarting anything. If it misbehaves, roll back to any previous version in one click.
Test before you enforce
Shadow mode runs a new policy against live traffic and records what it would have done, while it changes nothing. A/B splits traffic between versions so you can compare outcomes on real events. You answer the question every other tool leaves you guessing: what would this rule change have done to last week's real traffic?
Deterministic where it counts
The engine is deterministic: a rule built from deterministic checks gives the same verdict on the same inputs every time, and replays exactly. You decide where to spend that determinism and where to trade it for judgment: a rule can call a model or escalate to a human when the call is not clear-cut, and those parts are not deterministic by nature. The engine is honest about which is which, so a deterministic decision is provably reproducible and a judgment call is fully traced. Evaluation runs in two phases, so the verdict is settled before any side effect fires; events for one entity process in order, different entities in parallel.
Stateful, which most engines are not
Track state across events: counters, windowed counters, labels, and metadata - the primitives behind rate limits, velocity, reputation, and cooldowns. ACID and replay-safe. Stateless rule engines leave you to add a database and get event ordering right yourself. It is the difference between "is this request allowed" and "is this the fifth request this hour, and should the account now be held."
Inline 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, which is what financial risk and AI agents need. Or asynchronously: events stream in, text, images, transactions, get evaluated, and the outcome fires after, a block, an escalation to human review, a downstream action, which is how user-generated content moderation usually runs, at volume, without making the user wait. You choose per policy, and both produce the same versioned, replayable record.