One binary. You turn on the parts you need.

What you deploy

1. Your agents and your servicesan agent calls through a gateway, a service calls the API directly
2. Swiftward, one binarygateways, engine, review screens and API
3. Postgres, your SIEM, your reviewersstate and audit stay in your network
4. Models and toolsoutside your network, reached only when a rule allows

One image. The engine and the gateways run as one process — start with the engine and one gateway, add the rest later. Your reviewers and rule owners work in a console that runs beside it, from the same image and on the same Postgres.

State and audit live in Postgres, your own database. The binary and Postgres start in minutes and handle on the order of a thousand decisions per second on one server. That is enough for most deployments, and it is why a pilot needs no infrastructure project.

Scaling past one server was planned from the start, and every step is configuration: Kafka carries events to more workers, and ClickHouse holds analytics and the archive. The engine does not change.

Two ways in. An agent calls through a gateway, and the only change on its side is one endpoint URL. Or your own service calls the API directly before it acts.

What leaves. Only what your configuration sends: decisions to your SIEM over syslog, calls to other systems over webhooks, and the model and tool calls your rules allow. The decision record stays in your Postgres. A tool call goes out only if the caller was granted that tool, and a prompt passes the redaction you configured before it goes to a model.

The two halves

The System pages explain how the platform works. The Controls pages cover what it stops. Each page says what it takes to run: rules alone, the Swiftward service itself, or rules that call a model or read an index.

If you read one page, read safe change. If you want the vocabulary first, start with concepts.

System

Concepts — event, entity and state, policy, signals, verdict, decision record.

Declarations — entities, screens, queues, roles and actions are declared, like the policy.

Engine — stateful, deterministic where it matters, in the request path or in the background.

Policy as code — who may edit a rule and who may promote it. A policy owner edits without an engineering ticket.

Safe change — the four states of a version, and backtest, shadow and A/B before you promote.

Gateways — where it sits in the call path, and what happens when it is unreachable.

Human review — queues, the screens a reviewer works in, and where the decision is recorded.

Audit and evidence — a record that shows any alteration afterwards.

Data retention — what is kept, and for how long.

Observability — logs and metrics into your own tooling.

Integrations — your identity provider, your SIEM, the detectors you already pay for.

Secrets and data classification — credentials kept in one place, and each sensitive field labeled once.

Administration — who operates it, how they sign in, multi-tenancy.

Security — what your own team can verify without taking our word for it.

Controls

In the order a request meets them.

Registries and documentation — what agents exist at all.

Authentication and authorization — who is calling, and a sequence of calls that is not allowed even though each call in it is.

Injection detection — instructions hidden in a prompt or in data the agent reads, and whether the model's reply shows they worked.

Data redaction — what must not leave, in both directions.

Code fingerprinting — recognizing your own source code.

Role and judge checks — the assistant staying in the role you deployed it in.

Content classification — cheap classifiers on everything, expensive ones only on what the cheap ones flag.

Spend and loop limits — a counter on calls, dollars or retries, and what happens when it reaches the limit.

Business rules — stateful rules where a wrong decision costs you.