rotascale

Platform — Authority

Authority is a statement, not a role.

A grant says what one named agent may do, up to what value, until when, and under what conditions — signed for by an accountable human. A role says who someone is. A grant says what they may do, bounded and expiring.

The Authority screen on the running demo, listing grants with their scope, window and remaining budget. The Authority screen on the running demo, listing grants with their scope, window and remaining budget.
Grants on the running demo. Each one names an agent, an accountable human, a scope, a window and a ceiling — and what is left of it. observed →

Four rules that hold whatever the tree looks like

Nothing unowned holds power

An agent without a named accountable owner cannot be granted anything. The refusal is the control — an agent nobody answers for cannot be given authority by accident.

observed →

Delegation subdivides, never multiplies

A delegated grant cannot exceed its parent on scope, window, budget, conditions or enforcement mode. Spending against a child debits every ancestor, so a tree of grants cannot sum to more than its root — which is the property that makes an orchestrator handing work to a specialist safe rather than a multiplier.

observed →

Revocation reaches the whole tree

Revoking a grant revokes everything delegated from it. And the question that always follows — was anything allowed afterwards — is one the platform answers, rather than leaving you to trust that it wasn't.

observed →

High-value authority takes two people

A grant above a threshold the regime sets is issued pending_approval and does nothing until a second named person signs it. The threshold is the regime's, not a preference.

observed →

The refusal does not depend on the agent's cooperation

Every refusal described so far requires the agent to ask. A compromised or badly written agent that simply calls the payment API directly is ungoverned, and a governance layer that only works against well-behaved software is advice rather than enforcement.

A capability token
When a grant names a resource, an allowed decision mints a short-lived token bound to that resource, that action and that amount.
Verified offline
The resource checks the signature against a published key. It does not call us, and it refuses a request with no token or an insufficient one — on evidence the agent cannot forge.
Held, not spent
Authority for a named resource is held until the resource says what happened. Settled debits the ceiling; released gives it back; and a hold nobody ever resolves expires and is reported as a finding, because an agent that obtained authority with no record of what became of it is worth knowing about.

What this does not do. A resource that never checks the token is still ungoverned. This moves the enforcement point to something the agent does not control; it does not reach systems that have not been instrumented, and no honest description of it says otherwise.