How Swiftward works
The concepts, the architecture, and how a policy is versioned and recorded. Written for the engineer evaluating Swiftward.
Core concepts
The thing that happened: a prompt, a tool call, an order, a transaction, a piece of content. It carries its own timestamp, and the engine evaluates against that.
The subject a decision is about: a user, an agent, an account, a session. Swiftward keeps state per entity — counters, counters over a time window, labels and metadata — and those build into rate limits, velocity and reputation. State is ACID and safe to re-process, so a rule can ask "is this the fifth request this hour," not only "is this one request allowed."
A policy is a versioned set of rules. A rule is conditions plus effects: when these signals are true, return this verdict and fire these actions. A policy moves through draft, candidate, frozen, archived. Deploying is a separate step, and a deployment rolls back by naming the previous version.
The computed inputs a rule reads: a PII match, an injection-classifier score, a velocity counter, an LLM-as-judge result, the output of your own function. A signal can be a deterministic check or a model call, and the rule decides which of the two it relies on.
The verdict is one of approved, flagged, or rejected. The effects around it: redact a field, open a human review case, update a counter, fire an alert or a webhook. A deterministic phase decides the verdict before any side effect fires.
The append-only record of one decision: the signals computed, the rules that matched, the state that changed, the verdict, and the record hash. It answers a dispute, and it is what you hand an auditor.
How a decision is made
An event arrives through a gateway or the API. The engine loads the entity's state, computes the signals the policy needs, and runs the rules in two phases: a deterministic phase decides the verdict, then a second phase carries out the side effects.
Every step is written to the decision record. What the engine guarantees while it does that — ordering, determinism, state — is on the engine.
A rule built from deterministic checks gives the same verdict on the same inputs every time. Where a rule calls a model or opens a case for a person, the record shows what the model returned and who decided the case. More on the engine.
Architecture and deployment
One image, and Postgres for state and audit. What that costs to run and how it grows is on the platform overview.
Writing policy
Policy is configuration: structured, versioned, and readable as a diff. You can run a version in shadow against live traffic before it decides anything. Two rules below: one reads state in a condition, the other writes it in an effect. It writes from the event that says the money moved, never from the decision to allow it.
rules:
refund_needs_an_operator_for_the_day: # on: mcp.input · tool: refund_transaction
all:
- path: "state.user.buckets.refunded_today"
op: gte
value: "{{ constants.operator_approves_daily_total_above_usd }}"
effects:
verdict: flagged
count_executed_refunds:
all:
- path: "event.type"
op: eq
value: "mcp.completed"
- path: "event.data.status"
op: eq
value: "success"
effects:
verdict: approved
state_changes:
user:
change_buckets:
refunded_today: "{{ signals.refund_amount }}" That is the shape of every rule. The language goes further — priorities, error fallbacks, action profiles — and your own scoring comes in as a rule that calls your service over HTTP, so nothing of yours runs inside our process. A signal that calls out of the process is declared as such, and the record keeps what it asked and what came back.
Go deeper
- The engine: versioning, shadow and A/B, determinism, stateful decisions.
- Audit and evidence: the decision record, hash-chaining, SIEM forwarding, retention.
- Gateways: LLM, MCP, network, FIX, SCM, blockchain, how identity and keys are handled, and how three of them together set the limits on what an agent can reach.
- Prompt injection guide and the maturity model.