Governed autonomy

What autonomy grant changes mean for a running mission

Autonomy grant changes don't reset running missions: they finish under their starting grant; new acts need the current level. See what carries over.

6 min readGoverned autonomy
On this page5

An operations desk at night lit by calm blue screensAn operations desk at night lit by calm blue screens

Autonomy grant changes do not rewrite work already running: a mission finishes under the grant it started with. New acts must meet the current autonomy level, so a change affects what can begin next, not the grant already governing a running mission.

What you’ll learn

  • What a running mission keeps when its autonomy grant changes
  • How the current level applies to new actions
  • How grant scope can vary by domain and action
  • What to review before changing a grant

What do autonomy grant changes mean for a running mission?

A grant change can affect what may happen next without changing the authority that started work already in progress. Keep those two questions separate: which grant governs a running mission, and what level applies to a new act?

A running mission finishes under its starting grant. Changing the current level does not replace that grant for the mission already underway. New acts, by contrast, must meet the current autonomy level. A change can therefore alter what is allowed to begin, even while existing work continues under its original grant.

This distinction matters when a plan crosses from intent into action. A plan can look settled while the authority behind future work has changed. Check the mission’s status and the permission for the next act separately. Do not infer permission for new work from the fact that related work is already running.

The autonomy page and autonomy as a contract are useful places to understand the terms. The practical question remains specific: is this act part of a mission already running, or is it a new act that must satisfy the current level?

Which grant applies to work already in progress?

Start by identifying the mission that is already running. Then establish the grant under which it started. That starting grant governs the mission as it finishes, even if the current autonomy level changes in the meantime.

Keep the scope narrow. This rule concerns the mission already underway; it does not turn the starting grant into open permission for later work. A new act needs to meet the current level. If the work has not started, do not treat it as protected by a grant attached to another running mission.

Example: A fictional repair company has a mission underway to inspect a damaged delivery van under its starting grant. The company changes its current autonomy level while the inspection is happening. The inspection continues under the grant it started with, but scheduling a replacement van is a new act and must meet the current level.

Important: Do not treat a running mission’s starting grant as permission for new acts.

When reviewing the work, keep the mission and its grant visible together. Brainis states that running missions finish under their starting grant, while new acts require the current level. The missions page is the relevant place to review missions, but the decision still depends on whether the act is part of work already running or is new.

What must meet the current autonomy level?

Every new act must meet the current autonomy level. The check is not only about the broad task. Authority can be scoped by action and domain, as well as by value, risk, reversibility, time, and owner. A level that applies in one domain or for one action should not be assumed to apply everywhere.

Work statusGrant that appliesWhat to check
Mission already runningThe grant under which it startedConfirm the mission is already running and identify its starting grant
New act within a domainThe current autonomy levelCheck the action, domain, and any other relevant scope limits
Work not yet startedThe current autonomy level for the proposed actConfirm the proposed act fits the current level before it begins

Per-domain levels make it clearer where authority applies. Brainis describes autonomy as earned and visible, with per-domain levels, nine trust metrics, and upgrade offers backed by receipts in the Autonomy Center. Use the level and scope that apply to the proposed act; do not substitute a general impression of trust for that check.

This is why autonomy grant changes can have different effects across work. A change may leave a running mission under its starting grant while changing whether a separate act in a particular domain can begin. Review the proposed act, rather than relying on the status of nearby work. The autonomy page describes where to look for the level and scope.

An engineer watching several screens of soft moving light in a dark roomAn engineer watching several screens of soft moving light in a dark room

How should you review a grant change?

Use a short review that separates active work from proposed work. First, list the missions already running. For each one, record which starting grant applies. That makes clear what continues under the existing grant and avoids treating the current level as a replacement for it.

Next, examine each proposed new act. Check the current level and the scope that matters: action, domain, value, risk, reversibility, time, and owner. If one of those limits does not fit, do not treat the act as covered by a different mission’s starting grant.

Keep the decision and its limits clear to the people who approve work. Brainis describes autonomy grants as signed, expiring, renewable sign-off records. Renewal is a one-click action citing current metrics, and it does not happen automatically. The never-autonomous list remains permanently visible. These details make it important to distinguish a current grant from an expired one, and a renewable grant from an automatic renewal.

Review the current level before allowing a new act, even when a related mission is already running. For a deeper discussion of how autonomy is earned in practice, read earned autonomy in practice. The useful outcome is a clear record of which permission applies to each piece of work, not a single broad statement that all work is approved.

What should you do before changing a grant?

Before you change a grant, separate running missions from work that has not started. For every active mission, confirm the starting grant that governs it. That work finishes under its starting grant; the change does not rewrite that permission.

Then review proposed new acts against the current autonomy level. Check the scope for the action and domain, along with any limits on value, risk, reversibility, time, or owner. If the scope is unclear, resolve that before treating the act as allowed.

Make the change with affected owners aware of what applies to their work. They need to know which mission continues under its starting grant and which new acts must meet the current level. Do not rely on a grant change alone to communicate those distinctions.

A useful final check is to ask two separate questions. Which running missions continue under their starting grants? Which proposed acts meet the current level and its scope? Answering both keeps work already underway distinct from permission for what comes next.

Governed autonomyUnderstand

Brainis Team

Notes on running a company with Brainis, from the people building it and running on it.

Tell me about your company.

Start with an idea or the business you run. I’ll find your next move and get to work.

Free plan, no time limit · no card needed