# The approval-record scoring worksheet

**Ships with:** The Assurance Line.
**Who this is for:** anyone who owns an agent system that a regulator, auditor, or customer could ask
about. Engineering leads, risk and control functions, and the people who sign the attestation.
**Who this is not for:** teams still choosing a framework. Come back when something is in production.
**Time:** an afternoon for five records.

---

## What this measures

Not whether you have approvals. You do — everybody does. It measures whether an approval you already
collected can answer the question *"who authorized this?"* about a specific action, months later, to
someone who is not inclined to be generous.

The distinction matters because the two are not the same thing, and the gap between them is where
every failure in the episode lives. A human genuinely approved something. An action genuinely
happened. The question is whether the record binds the second to the first.

---

## The method

Pull **five** approval records. Not your best five — that defeats the exercise. Take the five most
recent, or five at random from the last quarter.

For each one, score the four questions below. Each is worth one point. **A record scores out of four,
and the interesting number is not the total — it is which question it fails.**

Do this on paper or in the table at the end. It takes about fifteen minutes per record once you have
found them, and finding them is often the first finding.

---

## Question 1 — Does the record name the principal?

**Not the account. The principal.**

*Pass:* the record identifies who or what took the action in a way that distinguishes it from anything
else that could have taken it. A specific service identity, a specific human, a specific delegation
from one to the other.

*Fail:* the record names a shared service account, a role, a team, or an integration. If four things in
your estate could have produced this record, the record does not name a principal.

> **The common failure.** An agent runs under a service account that predates it, shared with two
> batch jobs and a monitoring integration. The record is honest and useless: it says what account
> acted, and that account is not a principal.

**Score: ___ / 1**

---

## Question 2 — Does the record name the specific action?

*Pass:* the record describes the action at the granularity a person would need to decide whether it
was acceptable. Which record was changed, which payment was released, which customer was contacted,
which config was pushed.

*Fail:* the record names a capability, a category, or a workflow. "Agent executed customer-update
workflow" is a category. It tells you a class of thing happened.

> **The test.** Could someone reading this record, who was not there, tell you whether the action was
> the right one? If they would have to go and find out what actually happened, the record has named a
> category, not an action.

**Score: ___ / 1**

---

## Question 3 — Does the record state the boundary of what was approved?

This is the one that fails most often, and it is the one the episode is about.

*Pass:* the record states what the approval **does not** cover. An amount ceiling, a set of accounts, a
time window, a class of counterparty, a required condition.

*Fail:* the record records assent without extent. Someone approved. What they approved is inferred
from context that is no longer available.

> **Why this is the load-bearing one.** An approval without a stated boundary expands to fit whatever
> the system later does under it. Nobody decides to widen it; there was never an edge to widen. This
> is the mechanism by which an approval a human genuinely gave authorizes an action that human never
> saw — and it is not a bug in anyone's code.

**Score: ___ / 1**

---

## Question 4 — Does the record state when it expires?

*Pass:* the approval has an end. A timestamp, a run count, a condition that terminates it, or an
explicit review date that has teeth.

*Fail:* the approval is standing, or its expiry is a policy statement somewhere else rather than a
field on the record.

> **The test that separates these.** If the system stopped honoring this approval tomorrow, would
> anything break that should not? If yes, the approval is load-bearing and permanent, and "we review
> those annually" is a description of a meeting, not a control.

**Score: ___ / 1**

---

## Scoring the set

| # | Record identifier | Q1 principal | Q2 action | Q3 boundary | Q4 expiry | Total |
|---|---|---|---|---|---|---|
| 1 | | | | | | /4 |
| 2 | | | | | | /4 |
| 3 | | | | | | /4 |
| 4 | | | | | | /4 |
| 5 | | | | | | /4 |

### Reading the result

**Read the columns, not the rows.** A single record scoring 2/4 tells you about one record. A column
that fails five times out of five tells you about your system, and that is the finding worth having.

- **Q1 fails across the set** → you have an identity problem, not an approval problem. Fixing the
  approval format will not help until agents have principals. That is the reachability audit.
- **Q2 fails across the set** → your logging granularity is above the decision granularity. The
  approvals may be fine; you cannot demonstrate it.
- **Q3 fails across the set** → the common case, and the subject of the approval-record worksheet. Your approvals record
  assent without extent.
- **Q4 fails across the set** → you have standing authority nobody re-decides. Pair this with the
  time-to-safe-state protocol in the time-to-safe-state protocol, because standing authority and slow revocation compound.

### What a good result looks like

Not 20/20. **Very few production estates score above 2/4 on a random sample**, and a team that scores
1/4 and knows exactly which column failed is in better shape than a team that has never counted.

---

## What this worksheet does not tell you

It scores the record, not the decision. A record can pass all four questions and describe an approval
that was substantively wrong — someone with authority approved something they should not have. That
is a different problem and this instrument does not touch it.

It is also not a compliance artifact. Nothing here maps to a control framework, and it is not
evidence for anyone. It is a diagnostic you run on yourself.

---

*Vikram Jha · The Assurance Line · vikramjha.work*
*Free to use, copy, and adapt inside your organization. No attribution required, no sign-up, nothing
gated. If you run it and the result surprises you, I would genuinely like to hear what column failed.*
