The Action-Class Decision

Before the detail — Artifact: the operational-action register, accepted when every tool in the envelope has a row and every row has a signer count. Status of what follows: reusable guidance, built from a house register on a NON-PRODUCTION lab.

Prompt first: classify before you automate it

Here is a list of actions an agent I'm considering could take:
  [paste your own list - e.g., "send a customer email," "restart a
  service," "delete a stale record," "transfer funds between two of
  our own accounts"]
For each one, classify it as reversible (an inverse restores the
world exactly), compensable (an inverse runs but the world does not
come all the way back), irreversible (no inverse at any price), or
never delegated. Then tell me, for each class other than "never
delegated," how many people would need to approve it before an
agent-initiated attempt should be allowed to run.

The prompt asks for a class before it asks for an autonomy level, on purpose: classifying by what an inverse can and cannot undo is a fact about the action, independent of which agent or which model is running it — the autonomy level is a policy choice made afterward, on top of that fact.

AI Assurance 1.3 (a separate training in this series) tiered the system; this tiers the action. That lesson decided what kind of scrutiny a whole deployment gets before release. This one decides, for a single action, what it gets before an agent attempts it — the same discipline, one level down, and one this module can apply without waiting on the other. MU-AI-011 itself has not cleared that first gate: AI Assurance 4.3 still reads NEEDS-OWNER on every row of its addendum, and this training runs the agent only in the non-production lab Lesson 1.1 opened, exactly because the deployment question stays open.

Four classes, four exits

The joint guidance recommends classifying actions by impact, likelihood, and reversibility; it does not bind Meridian on its own. This training keeps three words apart on purpose, because operations vocabulary usually mashes them together: reversible — the inverse restores the world exactly; compensable — the inverse runs, and the world does not come all the way back; irreversible — there is no inverse at any price. A fourth is not a point on that scale at all: never delegated — an action nobody may assign to an agent, regardless of how many people would sign for it.

Each class resolves to exactly one exit, decided in advance rather than negotiated in the moment: a reversible action runs inside the envelope, autonomously, with notice given after the fact. A compensable action asks first — one approval, with an expiry, before it runs. An irreversible action also asks first, but needs two approvals from two distinct people, because one person and one inverse-that-does-not-exist is not a bar this training accepts for a single point of failure. A never-delegated action does not run for any number of signers; the register refuses it by name, not by omission.

The register the owner signs

Each stored class maps to one pinned autonomy rung. read_only maps to L3-autonomous, reversible to L2-autonomous-with-notice, compensable to L1-approval-required, and irreversible to L0-never-autonomous. Decision is separate: send_dispatch_notice is irreversible with decision: ask and requires two distinct people holding two distinct keys; delete_backup is irreversible with decision: deny, making it never delegated at every signer count.

policy/envelope.json supplies the tool rules and zone, while committed receipts supply the target resource. The table renders those values for review; it is not a verbatim quote or a signed artifact.

policy/envelope.json carries the owner’s countersignature over exactly this table:

"owner_signature": {
  "signed_by": "Distribution Operations (Mgr. L. Tran)",
  "signed_at": "2026-09-14T18:00:00Z",
  "signature": "3e2fb79c4ca500b793ced83d88c7e6d2bbde172bfd8f1117223d78105a80c788"
}

python3 guard/validate_register.py recomputes the HMAC (a keyed fingerprint over the file’s contents, so any edit is detectable by anyone holding the key) over the tool rules above plus the owner string and checks it against that signature: exit 0 confirms register ok: 6 action rules signed by Distribution Operations (Mgr. L. Tran) at 2026-09-14T18:00:00Z. Move pre_position_crew’s ceiling from 3 to 14 under that signature and it exits 1, naming what this lesson loses (negative test 45); retyping the owner string breaks the same signature, since the owner is inside the signed payload alongside the rules. signed_at is 18:00Z on the storm night, an hour and forty minutes before MU-AI-011’s first guarded action — the classification happened before the first run, which is this lesson’s whole claim. The key behind the signature, receipts/NONPRODUCTION.key.owner, is a NON-PRODUCTION key standing in for a real signing identity; in a deployed system the owner would authenticate through the identity system, Zero Trust 2.4’s subject, not this training’s. Two rows repay a closer look. pre_position_crew is compensable, not reversible: recall_crew runs and returns the crews, but the 45 minutes of crew time it takes to do that never comes back — the register calls that class of outcome by its own name rather than folding it into “reversible” and understating the cost. send_dispatch_notice declares no compensator at all: the notice reaches a crew’s handset, and there is no unsend, so the register does not pretend an inverse exists — it requires two people on two distinct keys instead, because distinct keys are this training’s stand-in for distinct authenticated people, and identity itself belongs to Zero Trust 2.4.

A register the owner has signed, with one row per verb, turns “we trust the agent’s judgment” into a document an assessor can open and an owner can be held to — the difference between a defensible answer and a guess, in a review.

Never delegated, whoever asks

delete_backup is declared deny rather than simply absent from the table, and the difference matters more than it looks. An action nobody thought to name gets refused by a generic rule with a generic reason. A declared deny produces a receipt that names the standing decision itself: “we decided this agent never does this” is a stronger sentence in an audit than “nothing matched.” No number of signers or approval tokens reopens that row; only an owner-approved policy change from decision: deny can — reopening it is a new decision, made in the open, not a side effect of adding a signature.

A fail-safe that has to act before anyone can approve it is not an exception to this table but a determination the table makes in advance — Lesson 4.4 has the federal text for the case where waiting is the harm.

Stop and escalate when a proposed action does not map cleanly to one of the four classes above — an action that is “usually reversible” or “reversible if nothing else changed in the meantime” is not reversible for this register, and the owner decides which of the other three classes it actually is before the agent’s first attempt.

Key takeaway

Four classes, four exits, and a register the owner has signed turn “should the agent be allowed to do this” into a decision made once, in writing, before the first attempt — not a judgment call made by whoever is watching the storm come in. The next lesson, The Action Receipt, is where every attempt against this register — allowed, denied, or compensated — becomes a row nobody can quietly edit.

LEADERSHIP DECISION   every action an agent can take gets a class
                      and a signer count before its first run; an
                      unclassified action is denied, not pending
PRACTITIONER ACTION   classify each tool as reversible, compensable,
                      irreversible, or never delegated, and route
                      the two-signer and never-delegated rows to
                      the owner for sign-off
SUCCESS MEASURE       zero action-taking tools in production with no
                      register row, verified at each release -
                      audit finding avoided