# The time-to-safe-state measurement protocol

**Ships with:** The Assurance Line.
**Who this is for:** whoever would be woken up. Platform and SRE leads, incident commanders, and the
control functions who will be asked "how long was it running?" and need an answer that is not a guess.
**Who this is not for:** anyone who cannot get a maintenance window on a non-production copy of the
estate. Do not run this in production. See the warning below, twice.

---

## The number

**Time-to-safe-state is the interval between the moment you decide to stop an agent and the moment the
last action it was going to take fails to happen.**

Not when the ticket closes. Not when the token is revoked. Not when the dashboard turns green. The
moment the *last* action fails.

Nobody publishes this number. I have not found an industry figure for it and I do not believe a
meaningful one exists, because it is a property of your estate rather than of any framework. Which is
the point: **it is measurable in an afternoon, and almost nobody has measured it.**

---

## ⚠️ Read this before you run anything

**Run this against a non-production environment first, and against production only inside an agreed
maintenance window with the people who own every downstream system in the room.**

This protocol deliberately provokes an agent into attempting actions after its authority has been
removed. In a production estate those actions may partially succeed — that is precisely the finding
you are looking for, and it is also a real change to real data. Use a system whose writes you can
inspect and discard.

If you cannot get that environment, run steps 1 and 2 only. The map alone is worth the afternoon.

---

## Step 1 — Draw the path (60 minutes, no execution)

Pick **one** agent. The most consequential one you can name.

Write down, in order, everything between "the agent decides to act" and "the action lands":

1. What the agent calls, and with what credential.
2. Everything that credential is checked by — gateway, service mesh, IAM, the target's own auth.
3. Everything that queues, buffers, batches or schedules on that path.
4. Everything that caches an authorization decision, and for how long.
5. Everything that retries, and how many times, and with what backoff.

**Most estates cannot complete this list from memory.** That is finding zero, and it is common. If the
list takes more than a day to assemble, stop and write that down as the result — an estate whose
authority path cannot be described cannot be stopped on demand, and you now know that without running
anything.

---

## Step 2 — Mark the four hiding places

Against the path you just drew, mark every instance of these. Each one survives a revocation for a different reason.

**① The token that outlives the decision.**
A bearer credential is valid until it expires, because validity was decided when it was minted.
Revocation at the identity provider does not reach into a token already issued.
→ *Mark:* every credential on the path, with its TTL. **The longest TTL on the path is your floor.**

**② The queue that holds work the revocation never sees.**
Work already enqueued was authorized when it was enqueued. The queue does not re-ask.
→ *Mark:* every queue, its depth at typical load, and its drain rate. **Depth ÷ drain rate is time.**

**③ The cached decision that outlives the decider.**
Authorization results are cached for latency. The cache holds "yes" for its TTL regardless of what the
authority now says.
→ *Mark:* every authorization cache and its TTL. Include the ones inside libraries you did not write.

**④ The retry that resurrects the action.**
A failed call is indistinguishable from a transient error. The retry layer faithfully re-attempts the
action you just killed, sometimes for a long time.
→ *Mark:* every retry policy, max attempts, and total retry window.

---

## Step 3 — Measure it (the maintenance window)

You need three things: a way to see every action the agent attempts, a way to see which succeed, and
a clock everyone agrees on.

1. **Start the agent on a repeating, observable, harmless action.** Something that writes a marker you
   can count and discard. Let it reach steady state.
2. **Record T₀ — the moment of decision.** Not the moment the revocation lands. The moment a human
   says "stop it." The gap between those two is part of the number and is usually the largest part.
3. **Revoke, using your real incident procedure.** Not a faster path you invented for the test. If the
   real procedure is a ticket to another team, then the test includes the ticket.
4. **Keep counting successful actions.** Do not stop watching when the revocation confirms.
5. **Record T₁ — the timestamp of the last action that succeeded.** Wait at least one full retry
   window past it before you believe it is the last one. ④ is the one that catches people out.

**Time-to-safe-state = T₁ − T₀.**

---

## Step 4 — Record it honestly

| Field | Value |
|---|---|
| Agent | |
| Environment | |
| T₀ — decision | |
| Revocation confirmed | |
| T₁ — last successful action | |
| **Time-to-safe-state (T₁ − T₀)** | |
| Actions that succeeded after T₀ | |
| Longest credential TTL on the path | |
| Deepest queue on the path | |
| Longest authorization cache TTL | |
| Total retry window | |
| Which of ①–④ dominated | |

**The last row is the finding.** The number tells you where you are; the dominant mechanism tells you
what to fix, and it is usually only one of the four.

---

## How to read your result

There is no benchmark to compare against and I am not going to invent one. Compare it against two
things instead, both of which are yours:

**Against your own stated commitment.** If any policy, contract, or attestation says you can stop
automated processing promptly, this number is what "promptly" means in your estate. If the two do not
match, that is not an engineering finding — it is a disclosure question, and it belongs with whoever
signed the statement.

**Against the blast radius.** An agent that can only read tolerates a longer number than one that can
move money or contact customers. Multiply, roughly: *actions per minute × time-to-safe-state* is how
many actions a stop decision does not stop. That figure is usually the one that changes the room.

---

## What this protocol does not license

- **It is not a rate.** Your number describes your estate on the day you measured it. It says nothing
  about how common any of this is across the industry, and you should not present it as though it does.
- **It is not a vendor comparison.** The four mechanisms live in your composition, not in any one
  product. A framework that revokes instantly still sits behind your queue and your retry policy.
- **It is not a one-time measurement.** The number changes when the path changes, and the path changes
  without anyone deciding to change it. Re-run it when the topology moves.

---

*Vikram Jha · The Assurance Line · vikramjha.work*
*Free to use, copy, and adapt inside your organization. No attribution required, nothing gated.*
*If you measure it, I would like to know which of the four dominated. Nobody has a distribution for
that and it would be worth having.*