approvals · the gate
The run stops. A person decides.
A protected action does not happen because a model proposed it. The run halts at the gate, a person reads the slip, and the decision travels on with the work.
An approval is not a checkbox at the end of a form. It is a record, bound to four things, kept across restarts, and spent exactly once. The run that reaches it cannot talk its way past it, and nothing in the division can grant it on a person's behalf.
This page shows the gate from both sides: what the run sees when it stops, and what the slip records when a person decides.
the gate · in motion
One run, one hatch.
01 · the run arrives
A run reaches a protected action.
The card is the run. It carries what it has retrieved and what it proposes to do next. The hatch is closed and the lamp is dark.
the slip
What the slip records.
Read down the stages. The slip on the right keeps every line.
01
Bound to four things.
An approval belongs to one tenant, one authenticated principal, one run and one immutable version of the action. Another tenant, principal or run cannot find it, let alone decide it. Two keys, or two issuers, are two identities.
The version matters most. A person approves the exact arguments they read. If the run later proposes different ones, that is a different action and needs its own approval.
- tenant
- acme
- principal
- key_7f3a
- run
- 01HV3Q7KX2
- action
- send second reminder · invoice 0417
- version
- 3
02
Checked again before dispatch.
Immediately before the action is sent, the full inputs, the tool's schema and tier, the workspace and any delegated context are checked once more against what was approved. A changed argument is blocked, even one that was outside the summary the person saw.
The check does not trust the screen. It trusts the stored version.
- inputs
- complete · evidence 2 of 2
- tool
- send_reminder · protected tier
- workspace
- finance · delegated context verified
03
Decided by a person, in time.
Pending decisions and their outcomes are retained in the database, so a worker restart or a dropped stream loses nothing. Expiry is decided by the database clock, not by the browser. A decision made before expiry cannot be dispatched after it.
A required approval never falls through. A missing state, an unavailable sandbox, an allowlist or an automatic review does not satisfy it. Only a plan marked advisory may continue past an observed expiry, and it says so.
- decision
- approved · version 3
- by
- credit controller
- at
- 2026-11-01 09:42 · expiry 10:00
04
Spent exactly once.
Consuming the approval authorises one dispatch attempt. Repeating the same decision is safe and changes nothing. Opposite decisions conflict and the second is refused.
An expired or rejected action is not reset. It needs new work and a fresh review, and the old slip stays on the record as it was.
- dispatch
- 1 of 1 authorised
- receipt
- run 01HV3Q7KX2 · line 14
what stops a run
Where the gate stands.
Five kinds of action halt a run today. Mandates, when they arrive, will set the same gates per role.
- Sending outside
- how it is set todayThe tool that sends sits in the protected tier: email, message, letter. The run stops before anything leaves.
- with mandatesA limit on outbound messages per role, with its approver named.
- Moving money
- how it is set todayPayment, refund and credit-note tools are protected. Vellon carries the action; Q enforces the approval.
- with mandatesAn amount per role, and who signs above it.
- Changing a record
- how it is set todayTools that delete, archive or merge a record in a connected system are protected.
- with mandatesSet per department, for the records it owns.
- Spending past the limit
- how it is set todayA budget pause holds the run when its spend reaches the limit. It waits to be lifted.
- with mandatesThe mandate's own budget, per role.
- A step the plan names
- how it is set todayThe plan's approval policy stops the run at that step, whatever the tool.
- with mandatesWritten into the mandate once.
The protected tier, the plan approval policy and the budget pause exist today. Mandates are in design and nothing on the right of this table is live.
the states
Five states, no sixth.
pending
Waiting
A person has not yet decided. The run holds.
approved · rejected
Decided
Recorded, not yet dispatched. Rejection ends the action.
expired
Too late
The clock ran out first. New work, new review.
consumed
Spent
One dispatch was authorised and taken.
conflict
Refused
A second, opposite decision arrived. It is not applied.
limits
What the gate does not do.
It does not decide. A person does, in the app or over the API, with the version in hand. It does not summarise the proposal into something easier to approve: the full inputs are there to read.
It does not yet know departments or roles. Approvers today are principals with approval rights on the tenant. Per-role approvers and limits arrive with mandates, which are in design.
Delivery to the connected system is at least once. The approval is spent once; the system on the other side must tolerate a repeated delivery, and the receipt shows if one happened.