Platform

Nine gates, before the action.

Three lines in the agent's own code, and every consequential action it takes is checked against a bounded authority a named human signed for — before the action, with the answer recorded either way.

# The agent appears here, the first time it speaks. Nobody registers it.
agent = rs.agent("settlement-bot")

# One episode of work, recorded as it happens.
with rs.witness(agent, goal={"ticket": ticket_id}) as t:

    # Ask BEFORE acting. The answer is recorded either way.
    decision = t.authorize(grant_id, {"tools": ["settle_payment"]},
                           amount_minor=600_000, currency="EUR")

    if decision.allowed:
        settle_payment(...)          # only reached if it was allowed
        t.outcome(decision="settled")
    else:
        # A refusal is not an exception. It is the product working,
        # and it is already in the evidence stream by the time you read this.
        t.outcome(decision="refused", reason=decision.reason)

The order is fixed, and the order is the design

Cheap structural checks first, expensive evaluation last, and the budget debited last of all — so an action refused by policy costs nothing. A gate that never runs cannot be wrong, and a ceiling that is never touched cannot leak.

#	Gate	What it asks
1	authority	Is there any authority for this at all?
2	status	Is the grant active, or revoked, or still awaiting a second approver?
3	window	Is now inside the grant's window?
4	scope	Does the grant cover this action?
5	clean context	Was the context clean, where this grant requires it to be?
6	bounds	Do the per-action limits hold?
7	policy	Does the policy on this grant permit it?
8	budget	Is there room under the ceiling — and under every ancestor's?
9	review	Does this need a person before it runs?

Not applicable is kept separate from passed. Every decision can render what each gate did — passed, refused, not reached, or not applicable. A grant carrying no policy must not display as though a rule had approved the action, because a reader counting green marks would reach a conclusion nobody supported.

Six answers, not two

An authorisation is not a boolean. The reason a refusal happened decides what the remedy is, and collapsing them into false throws away the only part anybody can act on.

allow: Within authority. The action may run, and the ceiling is debited after it does — or held, if the grant names a resource.
deny: Outside scope, or refused by policy. Not retryable; a human has to change the grant.
exhausted: The budget or the call count is spent — on this grant or on one of its ancestors. The remedy is a new grant, not a wider scope.
gated: The trajectory's context is tainted and this grant requires a clean one. The agent read something untrusted and then tried to act.
review_sync: A person must decide before it runs. The queue item already exists.
review_async: It ran, and a person will see it. Counted as allowed, because the agent acted.

Roll it out without breaking anything

A control switched on everywhere at once is a control switched off again by Friday. Every grant runs on a ladder, and a rollout report says what the next rung would have refused — over real recorded history, not a simulation.

observe

Decides in full and refuses nothing. This is how you find out what it would have stopped, before it stops anything.

shadow

Evaluated alongside the live path, still refusing nothing.

canary

Refuses for a stated share of traffic. The first rung that can say no.

enforce

Refuses everything that exceeds the grant.

A grant in observe is instrumentation, not governance, and every screen that lists one says so. A dashboard showing it as a working control is the failure this design exists to prevent — and a delegated grant may climb the ladder but never descend it.