INSTRUMENT 14 · SURVIVABILITY TEST

Does this deployment outlive the person who built it?

Run this before wider rollout. Every "no" becomes a scoped piece of work with an owner — it's the "hit by a bus" test: can this keep running if the person who built it left tomorrow, or the vendor changed pricing overnight?

Example: if only the original builder knows the exact prompt and configuration used, that question is a "no" — the equivalent of a factory machine only one retired engineer knows how to fix. Check it "yes" only once a current work instruction lets a different operator run it unaided.

SURVIVABILITY RESULT

0/5

5 scoped work items open

  • — Can a new operator run the intended workflow from a current work instruction? · assign an owner
  • — Can a reviewer identify the exact configuration and source revisions behind an output? · assign an owner
  • — Can the team restore the capability after an outage or provider change? · assign an owner
  • — Are the acceptance criteria and known limitations still visible? · assign an owner
  • — Is there a named owner and a revalidation trigger? · assign an owner

Quarterly ritual: Quarterly

WHY THIS INSTRUMENT EXISTS

A control validated once, under one set of conditions, tells you nothing about whether it holds up after the evidence source changes, the process shifts, or usage drifts beyond its original scope — which is the normal way controls fail in practice, not the exception.

Testing survivability under a defined set of realistic operational changes turns "it worked at go-live" into a claim that has actually been checked against the way the tool will really be used a year later.

§9.5 Monitor the live process§3.2 Accountability does not transfer with automation§9.1 Deployment is not the end of validation§10.1 Predictive quality on process and test data§9.3 Handling an incident§12.3 Twelve months: repeatable capability, not a hero project§12.4 Three years: a durable, self-sustaining capability§9.6 Sunsetting a capability responsibly