How Swiftward works
The concepts, the architecture, and how a policy is written, versioned, and replayed. 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. Every event carries its own timestamp, and the engine evaluates against that, not the wall clock.
The subject a decision is about: a user, an agent, an account, a session. Swiftward keeps state per entity (counters, windowed counters, labels, and metadata - composed into rate limits, velocity, and reputation), ACID and replay-safe, so a rule can ask "is this the fifth request this hour," not just "is this one request allowed."
A policy is a versioned set of rules. A rule is conditions plus effects: when these signals hold, return this verdict and fire these actions. A policy moves through a lifecycle (draft, candidate, frozen, archived); deploying is a separate step, and a deployment rolls back in one click.
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 deterministic or a model call; the rule decides which it trusts.
The verdict is one of approved, flagged, or rejected. Around it come the effects: redact a field, open a human review case, update a counter, fire an alert or a webhook. The verdict is settled in a deterministic phase before any side effect fires.
The complete, append-only record of one evaluation: the signals computed, the rules that matched, the state that changed, the verdict, and the record hash. This is what you replay and what you hand an auditor.
How a decision is evaluated
An event arrives, through a gateway or the API. The engine loads the entity's state, computes the signals the policy needs, and evaluates the rules in two phases: a deterministic phase that settles the verdict, then a phase that carries out the side effects. Events for one entity process in order; different entities run in parallel. Every step is written to the decision trace. Because the verdict is settled deterministically, a decision built from deterministic rules replays exactly; where a rule defers to a model or a human, the trace still records exactly what happened and why. More on the engine.
Architecture and deployment
Swiftward ships as a single binary whose roles you turn on as you need them: the evaluation engine, the gateways, the human-review surface, the API. State and audit live in Postgres, ACID; add Kafka for transport, ClickHouse for analytics and archive, or Redis for cache by configuration as volume grows. It runs on your infrastructure, in your network: nothing leaves your environment, and decisions and audit events forward to your SIEM over syslog and to anything else over webhooks. The enterprise foundation · Security.
Writing policy
Policy is configuration, not application code: structured, versioned, diffable, and testable in shadow against live traffic before it enforces. Here is one rule that escalates a repeat offender, reading state in a condition and writing it in the same pass:
rules:
# Read state in a condition, write it in the effect.
repeat_offender:
all:
- path: "event.type"
op: eq
value: "ugc.post.created"
- path: "signals.toxicity_score"
op: gte
value: 0.9
- path: "state.user.counters.violations_30d"
op: gte
value: 3
effects:
verdict: rejected
state_changes:
user:
change_counters:
violations_30d: 1 That is the shape of every rule. The full language goes further - rule priorities, your own signal functions through an extension API - and it opens up with design partners as we scope a pilot.
Go deeper
- The engine: versioning, shadow and A/B, determinism, stateful decisions.
- Evidence and audit: traces, replay, SIEM forwarding, hash-chained records.
- Gateways: LLM, MCP, network, FIX, SCM, how identity and keys are handled, and how three of them jail an agent completely.
- Prompt injection guide and the maturity model.
Want it on your own policies? See it on yours.