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, the gateways and the code that carries out actions 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.

Postgres holds state and audit, ACID, and it is yours. The binary plus Postgres comes up in minutes and handles on the order of a thousand decisions per second on a single box, everything on that one database. That is enough for most deployments, and it is why a pilot needs no infrastructure project.

Growing past that one box was designed in from the start, and every step is configuration. Events split across workers as they arrive, Kafka carries them, and ClickHouse holds analytics and archive. The engine runs unchanged through all of it.

Two ways in. An agent's call through a gateway, where one endpoint URL changes and nothing else, or a direct call from your own service before it acts.

What leaves. Whatever a rule sends: a decision to your syslog collector in RFC 5424, or a call to anything else over a webhook. The record stays in your Postgres. A model or tool call goes out only where your configuration lets it. The gateway checks which tools that endpoint offers and which of them this caller was granted. Your rules then decide the call itself, and the redaction you configured runs before the prompt leaves.

The two halves

System is how the platform works. Controls is what it stops. Every page below answers one of the two, and says what you have to run: rules on their own, a service you deploy, or rules plus something you host beside them.

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

System

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

Declarations — the policy is not the only thing you declare. Entities, screens, queues, roles and actions are declarations too.

Engine — deterministic where it matters, stateful, and declared rather than coded.

Policy as code — versions, review, promotion, rollback. A policy owner edits without an engineering ticket.

Safe change — draft, candidate, frozen, archived. Backtest, shadow, promote, roll back.

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 held once, sensitive fields 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 the sequence of calls where every call is allowed and the sequence is not.

Injection detection — what arrived, and whether the reply shows a takeover.

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 — any classifier, cheap gates and expensive judges.

Spend and loop limits — one counter, one limit, one stop.

Business rules — the rules with a price on getting them wrong.