Control what your AI is allowed to do. Prove every decision it makes.
Swiftward™ is the control layer for AI agents. Write your policy as versioned code and test a change against your own recorded history before it goes live. Months later, a disputed decision is answered from the record instead of reconstructed from logs.
Runs on your infrastructure. We never receive your data. What your security team can verify.
Built by Konstantin Trunin. He has spent a career on declarative, high-load platforms with deterministic engines, in regulated industries like finance and healthcare, in logistics, and in enterprise security reviews. Swiftward is that approach again, for policy. Konstantin on LinkedIn →
refund_needs_an_operator:
all:
- path: "signals.refund_amount"
op: gt
value: 2000
effects:
verdict: flagged
actions:
- action: hitl/create_case
params:
queue: "finance"
timeout_duration: "24h"
timeout_decision: "reject" Read the signals, decide, act. A person steps in where you want one.
Most tools stop after the second step and hand you a score. Every event leaves one record: the signals it read, the rule that decided, and the frozen version that rule belonged to.
Enterprise-grade from day one.
Most policy tooling is built SaaS-first, with enterprise bolted on later. Swiftward is the other way around. Embed it under your own product, and a security review finds all of this already there:
Your software decides. Someone outside your team makes you answer for it.
Your product is ready and the deals stall in security review. Embed the controls your buyers demand — on-prem, SSO, access control, audit — under your own brand.
Agents in production across your company: the ones your teams built, and the ones you bought from a vendor whose code you cannot read. One control layer over both.
By industry: Financial services · Digital assets · Insurance · Healthcare · Legal · User-generated content
By discipline: AI governance · Trust and safety · Risk and compliance
Source code that must not leave the building, in chip design, defense and quantitative funds: code fingerprinting.
Not for you if nobody outside your team ever asks why a decision went the way it did. That is a real answer, and it saves us both a call.
Change a rule without guessing what it will do.
- Author a ruleby the policy owner
- Backtest iton your recorded history
- Read what flippedevent by event
- Promoteor roll straight back
- Prove it afterwardsa record that shows any edit
You declare the top of the stack. The engine underneath does not change.
Which gateways you switch on, which rule packs you load, the queues and screens your people work in: configuration, not code. The engine and the foundation under it are the same binary in every deployment.
See how this compares to assembling it yourself on OPA, LiteLLM, ROOST, or Microsoft's toolkit →
The same grammar, whatever the decision.
signals:
pii:
udf: dlp/scan
params:
entity_types: [EMAIL_ADDRESS, PHONE_NUMBER, CREDIT_CARD]
rules:
the_model_never_sees_the_real_value:
condition: len(signals.pii.findings) >= 1
effects:
verdict: approved
response:
redact_input: true
redaction:
findings: "{{ signals.pii.findings }}"constants:
daily_volume_cap_usd: 50000
signals:
day_total_after_this:
expr: state.wallet.buckets.daily_volume + event.data.amount_usd
rules:
daily_volume_cap:
condition: signals.day_total_after_this > constants.daily_volume_cap_usd
effects:
verdict: rejected
response:
reason: "Refused. This transfer would take today's total past the cap."signals:
judge:
udf: moderation/llm_rulebook
rules:
enforce_the_policy:
condition: len(signals.judge.violations) > 0 && signals.judge.confidence >= 0.7
effects:
verdict: rejected
review_the_grey_zone:
condition: len(signals.judge.violations) > 0 && signals.judge.confidence < 0.7
effects:
verdict: flagged
actions:
- action: hitl/create_case
params: { queue: "trust-safety" }- Versioned policy lifecycle: draft, candidate, frozen, archived. Rollback by naming the previous version.
- Backtest: a candidate version runs over your recorded history, and its verdicts are diffed against the version live today.
- Shadow and A/B: a shadow arm decides nothing while it runs, and an A/B split is deterministic.
- Stateful decisions: counters, rate limits, sliding windows, circuit breakers.
- Human review: a rule opens the case, and the queue, the screens and the answer on timeout are declared.
- A failed event is held for retry, not dropped. Events split across workers as they arrive, with Kafka and ClickHouse added when the volume needs them, and the engine unchanged.
Policy is the last thing in your stack with no engine under it.
Feature flags got one. Workflows got one. The decisions your software is not allowed to get wrong still sit in application code, where nobody can version them, test a change, or prove later what they did. AI is where this hurts most today, so this site is about agents. The engine does not care what kind of decision it is: a post, a payment, a claim, a tool call.
Decisions are hash-chained, and a signed checkpoint over the chain can go to someone outside the deployment: your own archive, an auditor, a counterparty. Edit a decision later and the chain stops matching the checkpoint they hold.
Each case here names the system, the rules it ran under, and what they decided.
Bring us the decisions you need to control.
A 30-minute call. Pick the hardest one, and we go through how the engine would handle it.