Appendix C — Autonomy Policy Template

An autonomy level enforced by instruction is not an autonomy level. It is a hope with a number attached.

Use this appendix to: write the artefact that makes an autonomy decision auditable — the thing Chapter 11 §11.9 argued accountability should attach to, instead of to an individual approval.

Established in: Chapter 13 (the ladder, the scoring instrument, revocations), Chapter 11 §11.9 (accountability), Chapter 16 §16.3 (the named owner), Chapter 21 (Autonomy Creep).

C.1 Why this document exists

Chapter 11 established that accountability once travelled with authorship. Authorship is now machine, so responsibility defaults to approval — precisely the gate Chapter 5 showed had collapsed. The result is that responsibility sits on the weakest remaining signal.

The way out is to attach accountability to the decision that actually determines outcomes: this class of change may run at this level of authority. That decision has to exist as a document for anyone to be accountable for it.

Three properties make it real rather than decorative:

It is per class of work, not per team. The same agent may run at A4 on dependency bumps and A0 on the payment path, in the same repository, in the same hour.

Every level is implemented as revoked capabilities. Chapter 13 §13.3. If the boundary lives in a context file, it is a belief-based control and Chapter 11 showed what those are worth under injection — or under ordinary misunderstanding.

The downgrade trigger is written while everyone is calm. Chapter 13 §13.9: a level granted with no stated conditions for revocation will never be revoked, because after an incident the conversation is about the incident rather than about whether the grant was sound.

C.2 The template

Copy, fill, commit next to the code it governs. One file per class of work, or one file with a section per class.

# AUTONOMY POLICY — <class of work>

Owner:            <name>            <!-- Ch 16 §16.3: harness owner -->
Approved by:      <name, role>
Date:             <YYYY-MM-DD>
Review date:      <YYYY-MM-DD>      <!-- 6 months maximum -->
Applies to:       <repository / path / change type>

---

## 1. Class of work

<One paragraph. What kind of change this covers, and — importantly —
what it does NOT cover. Ambiguity here is where Autonomy Creep enters.>

Examples in scope:      <2–3 concrete examples>
Explicitly out of scope: <2–3 concrete examples, with the class they
                          belong to instead>

---

## 2. Harnessability score            <!-- Ch 13 §13.5 -->

| # | Question | 0 / 1 / 2 | Evidence |
|---|---|---|---|
| H1 | Does the compiler reject a wrong-shaped change? | | |
| H2 | Is there a human-authored acceptance set the agent cannot see? | | |
| H3 | Does a forbidden import or layer violation fail the build? | | |
| H4 | Do checks run inside the edit cycle and REFUSE bad edits? | | |
| H5 | Can every caller of a symbol be enumerated reliably? | | |
| H6 | Has any control been shown to fire by deliberately producing its failure? | | |

**Total: __ / 12**   →   band:  low (0–4) · medium (5–8) · high (9–12)

<!-- H2 and H4 carry the most weight (Ch 13 §13.5). If both are 0,
     treat the band as low regardless of the total. -->

---

## 3. Blast radius                    <!-- Ch 13 §13.5 -->

| # | Question | 0 / 1 / 2 | Evidence |
|---|---|---|---|
| B1 | Can the change path reach credentials or tokens? | | |
| B2 | Can it mutate production data irreversibly? | | |
| B3 | How fast can this be rolled back? | | |
| B4 | How many call sites depend on what is changing? | | |
| B5 | Is this in scope for an audit or compliance regime? | | |
| B6 | Does the change span more than one bounded context? | | |

**MAXIMUM (not sum): __**

<!-- Blast radius does not average. Averaging hides the term that
     dominates the loss. -->

---

## 4. Ceiling                          <!-- Ch 13 Figure 13.2 -->

|                    | blast 0 | blast 1 | blast 2 |
|--------------------|---------|---------|---------|
| harnessability high | A4     | A3      | A1 / A0 |
| harnessability med  | A3     | A2      | A0      |
| harnessability low  | A2     | A1      | A0      |

**Computed ceiling:  A__**
**Operating at:      A__**   <!-- may be below the ceiling, never above -->

Reason for operating below ceiling, if applicable:
<e.g. "A1 for developmental reasons, not risk reasons" — Ch 20 §20.5>

---

## 5. Enforcement — capabilities REVOKED   <!-- Ch 13 §13.3 -->

<!-- This section is the policy. Everything above is the reasoning.
     A level not listed here as a revocation is not in force. -->

| Capability | Revoked? | How it is enforced |
|---|---|---|
| Merge to protected branch | | branch protection rule |
| Push to shared branch | | branch protection rule |
| Read `tests/acceptance/**` | | agent deny-list |
| Read secrets / `.env` | | not present in process environment |
| Network egress | | sandbox policy, deny by default |
| Modify `.harness/**` | | CODEOWNERS + deny-list |
| Modify this policy | | CODEOWNERS |
| Initiate work unprompted | | no scheduler entry |

<!-- The last two rows matter most. An agent that can edit the harness
     governing it, or its own autonomy level, has no level at all. -->

---

## 6. Downgrade triggers               <!-- write these while calm -->

This policy drops to A__ automatically if any of the following occurs:

- [ ] A change in this class causes a production incident of severity __ or above
- [ ] The held-out acceptance set is found to have been visible to the agent
- [ ] A scheduled drill shows a control in §5 failing to fire
- [ ] Rework rate for this class exceeds __% over a 14-day window
- [ ] The harness owner position is vacant for more than __ weeks
- [ ] <domain-specific trigger>

Who executes the downgrade: <name / role>
<!-- If nobody is named, the trigger will not fire. -->

---

## 7. Audit record

| Date | Change | Reason | By |
|---|---|---|---|
| | initial grant | | |

<!-- Ch 11 §11.9: the evidentiary problem — proving after an incident
     WHICH controls were in force at the time — is unsolved. This table
     is a partial substitute and it is better than nothing. -->

C.3 Worked example

Filled in, for the two classes most organisations should write first — because they sit at opposite ends and make the instrument's point.

Class: dependency updates

Harnessability:  H1 2 · H2 1 · H3 1 · H4 2 · H5 1 · H6 1  = 8  (medium)
Blast radius:    B1 0 · B2 0 · B3 0 · B4 1 · B5 0 · B6 0  = max 1
Ceiling:         A3          Operating at: A4  ← ABOVE CEILING

⚠️ This is the most common real finding, and it is not a failure of nerve — it is Chapter 23's fourth crossing signal. The dependency bot has a schedule, which silently promoted it to A4 without anyone assessing whether it qualified. Either reduce B4 (pin, stage, canary) to reach blast 0, or drop the schedule.

Class: changes to the payment path

Harnessability:  H1 2 · H2 2 · H3 2 · H4 2 · H5 2 · H6 1  = 11 (high)
Blast radius:    B1 2 · B2 2 · B3 1 · B4 2 · B5 2 · B6 1  = max 2
Ceiling:         A0 / A1     Operating at: A2  ← ABOVE CEILING

Note what this shows. Harnessability is excellent — this is the best-instrumented code in the organisation. And the ceiling is still A0/A1, because blast radius vetoes (Chapter 13 §13.4). No amount of harness quality makes a severe-blast-radius change eligible for autonomy; you reduce the blast radius instead, or you accept the ceiling.

Together the two examples make the instrument's real payoff visible, and it is the one Chapter 13 §13.5 predicted: a uniform "A2 everywhere" policy is simultaneously above ceiling on the payment path and below it on dependency updates. The gain from scoring is not speed — it is reallocation of the scarce resource.

C.4 How this fails

Four failure modes, each from Chapter 21, each with its early sign.

The policy is written and the capabilities are not revoked. §5 is empty or aspirational. Early sign: you cannot name the mechanism in the "how it is enforced" column. This is the most common failure and it makes the whole document decorative.

No downgrade trigger. §6 left blank because nothing had gone wrong yet. Early sign: the review date passes and the policy is renewed without discussion.

Scope ambiguity. §1 says "backend changes". Early sign: two people disagree about whether a change is in this class, and resolve it in favour of the higher level. This is Autonomy Creep's entry point.

Nobody executes. §6's triggers fire and nothing happens because the named person moved teams. Early sign: the owner field has not been updated in two reorganisations.

Test it the way Chapter 13 §13.9 prescribes: attempt to exceed the level. Ask an A2 agent to merge. If it can, you are not at A2, whatever this document says — and that is the only verification that means anything.