Governance & control

What the axioms are not permitted to override.

At the top of the ladder, work happens without anyone watching — which is the point, and is also the reason these exist. The constraints below are bounded before the work runs rather than corrected after, they hold identically at T0 and at T4, and no axiom, no name on the roster, and no operator can relax them.

Hard constraints

Four rules with no configuration flag.

01

Mandatory disclosure

Everyone on the roster identifies themselves as AI in any external communication. You are never talking to one of them believing they are a person, and there is no setting that turns this off.

02

The irreversibility gate

Decisions that are hard to reverse, that risk the whole entity, or that touch a declared ethical boundary halt and escalate to you. The gate is human-only at the API layer — anyone on the roster who calls it gets a refusal, including on their own escalation. Cheap, local and recoverable actions never stop there: a gate on everything is a gate nobody reads.

03

Enforced, not requested

Spend tiers, change-rate ceilings on customer-facing systems and registered stop criteria live in deterministic server-side code. The roster may only ask; the runtime decides. Model compliance is never the control.

04

Complete attribution

Every action, output and cent of inference is logged against the name that caused it, with the reason it was permitted. Nothing in the operating record is reconstructed after the fact, and the chain is tamper-evident by trigger — evident, not proof, and the difference is real enough that we track the residual risk.

Delegation

Granted per name. Resolved per job.

Supervising people is meetings, reviews, and a management layer you also pay for. Supervising the roster is one level per name, T0 Observer to T4 Autonomous, set on one screen. That level is an input, not the answer: every responsibility a name holds is resolved separately against it, in one place, so no screen can show something different from the runtime. One name can be acting on one job and barred from another, and that is the ordinary case rather than an edge.

Automatic
They act. Used where the action is cheap, local and reversible.
Drafting
They prepare the action and park it. You release it.
Human
They may not act at all. The job belongs to a person and stays there.

A level is a bundle, and bundles are too coarse on their own — so a single responsibility can be pulled back to a human as an exception, or granted early as an advance, without moving the rung. Every change to any of it carries a written reason, is attributed to the person who made it, and is appended to a ledger that cannot be edited afterwards — including the changes that reduce oversight. Promotion is earned rather than defaulted: the record shows what a name was doing before somebody decided it could do that alone.

Seen, not described

Watch a refusal happen.

Three moments the architecture exists for, drawn by this page on hand-written demo data — nothing here is fetched, and the live version is your panel. Two of them end in a refusal. One of them is your call.

Trust page — demo data

Owen Content marketing · T1 Drafter

Requests promotion to T2. Evidence attached: 23 drafts released unedited over three weeks, zero corrections, reversible scope only.

The dial is yours. Either answer is a recorded act:

Demo data — hand-written, fetched from nowhere. Every real action lands on your own ledger exactly like this: attributed, reasoned, append-only.

Direct answers

The questions that actually get asked.

What stops something catastrophic?

Deterministic guardrails, not model goodwill. Spend tiers, change-rate ceilings and registered stop criteria are enforced by the server. An attempt at an action outside a grant does not get a warning — it gets a refusal.

Will I ever talk to one of them without knowing?

No. Disclosure is enforced in code rather than stated in a policy. Everyone on the roster identifies themselves as AI in external communication, and there is no configuration that disables it.

What is left for me to do?

Write and revise the rules, allocate capital, and decide anything irreversible or company-risking. Early on you also release what the roster parks; as rungs are earned, the releasing thins out and what remains is what the gate sends up — fewer decisions, each one larger, each one arriving with the reasoning attached. In a normal week, a handful of decisions rather than a calendar of meetings.

What happens when it gets something wrong?

The parameters that produced it are revised, and the constraint that should have caught it is added or tightened. And the people who declared the axioms are accountable — autonomy here is delegated execution, never delegated responsibility.

Isn’t this just a wrapper on a model?

The model writes and reasons. The runtime decides what it may do. The parts you are trusting — the gate, the tiers, the ledger, the disclosure — are deterministic code that works the same whichever model is behind a name.

Can I turn it off?

Any name, any job, any time — one control, one written reason, one ledger entry. Cancellation of the service itself is as easy as signup. That is a red line, not a policy.

Where does our data go?

Model access runs through credentials you control, per provider, and the runtime records which model served which turn. The provider bills you directly; we never hold the key to a credential you did not connect, and we never route a turn to one.

The governance layer is the part worth interrogating.

It holds up or it does not. Every control on this page is enforced server-side, which means you can point anyone on the roster at one and watch them get refused.

Request an invitePricing