§ 01 / DefinitionWhat the Actuator is
Most systems scatter their side effects. One tool restarts a container, another runs a database migration, a third calls a cloud API — each with its own credentials, its own logging, its own idea of what "careful" means. When those actions are being taken by AI agents, that scatter is the problem: there is no single place that decides whether an action is allowed, and no single record of what was done.
The Actuator collapses that scatter into one plane. It is a domain-neutral core with a small backend for each kind of system it can act on. Every action, whatever it touches, enters the same way, is checked the same way, and is recorded the same way. The value is not N action tools; it is one action plane.
§ 02 / PrincipleThe sense/act line is the gated/ungated line
The platform draws one clean cut through everything at its edge, and that cut does double duty. It is the anatomical line between sensing and acting, and it is the security line between what needs permission and what does not.
This is why the senses and the hands are separate services rather than two modes of one. The observing half sits entirely outside the gate, so it can be cheap and permissionless. The acting half sits entirely behind it, so nothing it does escapes review. There are no special cases to reason about: if it changes the world, it is the Actuator, and it is gated.
§ 03 / TiersFeeling and moving
Everyone understands that picking an object up is riskier than touching it. The Actuator makes that intuition the governance boundary. Actions split into two tiers, and the split is first-class, not an implementation detail.
- Query a live system on demand; change nothing. Inspect a container, run a read-only query. Reversible by nature — the worst case is you looked at something you shouldn't have.
- Lightly gated: scoped by capability, recorded as evidence, but no approval and no undo to declare.
- Change a live system, possibly irreversibly. Restart it, drop a table, remove a rule.
- Heavily gated, and every write carries three obligations before it runs: it must state why, declare how to undo it, and capture a snapshot of what it is about to change — then it is recorded and, by its risk, waits for a human.
An irreversible action — deleting data, powering a machine off — always requires a person. A reversible, low-risk one can be allowed to run on its own once it has earned that standing. The gate reads the tier as a first-class input rather than guessing per tool.
§ 04 / ReversibilityEvery move declares how to undo it
A write does not just happen and vanish into a log. Before it runs, it produces a reversal contract — a plain statement of what it did and the exact command that undoes it — and the snapshot needed to make that undo real. If the process dies mid-action, the durable record already names what was attempted and how to reverse it.
The reversal is documentation and audit, not silent automation — the system does not undo things behind your back. But it means that at every point, the answer to "how do we get back?" is written down at the moment of the change, by the thing making it, rather than reconstructed under pressure afterward. Some actions have no clean inverse; those are marked irreversible and treated with the caution that deserves.
§ 05 / ShapeOne package per target
The Actuator is a neutral core plus one small package per system it acts on. Each package implements the same narrow interface, so the core neither knows nor cares how a given target actually works underneath.
| Target | How it acts |
|---|---|
| host processes | Docker, systemd, Windows — containers, services, features, power. The action shells out on the machine. |
| a database | Queries and catalog reads on the read tier; schema and permission changes, with clean undos, on the write tier. The action runs over a connection. |
| a cloud API | DNS, cache, firewall rules, zone settings. The action is an HTTP request. |
Those are three genuinely different mechanisms — a subprocess, a database connection, a web request — behind one seam. That the same governance model fits all three without special-casing is the evidence the seam is drawn in the right place. A new target is a new package: it does not touch the core, the gate, or the other targets.
§ 06 / AuthorityEverything crosses the gate
The Actuator owns mechanism — the ability to do the work. It does not own authority — the right to permit it. Those are deliberately different things, held by different parts of the system.
By the time an action reaches the Actuator, the runtime has already checked that the caller was permitted to request it, taken a checkpoint if it is irreversible, waited for a human if the risk demands one, and written the intent to the tamper-evident record. The Actuator holds no permissions of its own; it carries out an action that was already authorized, and reports the result back onto the same record. Authority is requested through one gate and never self-asserted — the hands cannot decide to move on their own.
§ 07 / BoundariesWhat the Actuator is not
- Not a sensor. It does not observe the world's ambient state; that is the senses' job, and it stays outside the gate. The Actuator only ever acts, or reads a live system on demand.
- Not the authority. It owns how to do things, not whether they are allowed. The decision is made at the gate, upstream, every time.
- Not a place authority can be minted. It holds no standing permissions; an action arrives already authorized or it does not run.
- Not N bespoke action tools. The point is a single plane with one vocabulary and one door — not a growing pile of one-off integrations, each with its own idea of careful.