Chapter 10 — Playbook engineering and quality review

Lesson map

Lesson 10 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["10.1 A defective starting playbook, P0"]
  N2["10.2 A bounded specimen, P1"]
  N3["10.3 Walk the main case and a negative control"]
  N4["10.4 Score the playbook as a document, then test it"]
  N5["10.5 Measure outcomes without gaming them"]
  N6["10.6 A playbook is a decision interface, not a comma"]
  N7["10.7 Seven gates as a controlled workflow"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["10.1 A defective starting playbook, P0"]
  N2["10.2 A bounded specimen, P1"]
  N3["10.3 Walk the main case and a negative control"]
  N4["10.4 Score the playbook as a document, then test it"]
  N5["10.5 Measure outcomes without gaming them"]
  N6["10.6 A playbook is a decision interface, not a comma"]
  N7["10.7 Seven gates as a controlled workflow"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]

[Learning outcomes and connection]
    |
    v
[10.1 A defective starting playbook, P0]
    |
    v
[10.2 A bounded specimen, P1]
    |
    v
[10.3 Walk the main case and a negative control]
    |
    v
[10.4 Score the playbook as a document, then test it]
    |
    v
[10.5 Measure outcomes without gaming them]
    |
    v
[10.6 A playbook is a decision interface, not a comma]
    |
    v
[10.7 Seven gates as a controlled workflow]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes and connection

The learner can turn a case's decisions into a reusable, reviewable procedure with an entry condition, evidence boundary, role-specific approvals, tested branches, stop rules, rollback, communication gate and version history. A playbook is supplementary to this course's principal book: it supports supervised work but cannot supply authority by its mere existence. Chapters 1–9 provide the teaching and worked case; Chapters 11–12 will later exercise and assess the whole workflow.

The NIST SP 800-184 recovery guide discusses planning, playbook development, testing and improvement. NIST SP 800-84 provides exercise-program guidance. The specimen below is original CTN classroom text, not a NIST-issued template and not a ready-to-run response command. It contains no production access, credentials or instructions for disruption.

10.1 A defective starting playbook, P0

An invented draft P0 says:

If any sign-in alert mentions svc-enroll, disable the account. Restore the latest backup. Email all learners that a breach occurred. Close the case when the portal loads.

The sentence is short, but it is unsafe as an operational decision aid. “Any alert” lacks service effect and source quality. “Disable” lacks an approver, target scope and dependency review; CTN's shared account supports an approved job. “Latest backup” ignores data correctness and would have reverted S40/S41 in C26. “Breach” exceeds C31–C33's evidence and bypasses privacy/communications approval. “Portal loads” does not test authoritative slot state, alternate API writes, audit attribution, monitoring or rollback. The playbook has no version, owner, source reference, handoff or stop condition.

The repair should be a set of decision gates, not a longer paragraph that automatically performs the same actions. A useful playbook lets a novice pause safely, record uncertainty and contact the correct owner. Its success is measured by reproducible decisions and clear outputs, not by having many steps. Some steps must be conditional: if the authoritative state is correct, do not restore; if the owner is unavailable, escalate through the actual approved route; if a test fails, stop release and preserve the failure artifact.

10.2 A bounded specimen, P1

The following is P1, an unapproved teaching specimen designed from CTN's case. Its named inputs are synthetic. The real organization must adapt the scope, approvals, tools, law and contacts before use.

Lesson table; scroll horizontally to read all columns →

The specimen keeps human authority and evidence gates visible. It does not prescribe a command or a specific vendor feature. A local implementation would need an operator runbook with safe, authorized steps, but that runbook must be reviewed against actual architecture and is outside this classroom text. Links to supplementary Incident Response playbooks remain source-linked and retain their original rights.

10.3 Walk the main case and a negative control

For the main CTN case, gate 0 records C02 and service S42; gate 1 identifies C03–C05 and later C09's provenance gap; gate 2 assigns P2 at 09:14 because impact is plausible and detailed IdP records face a stated 10:00 expiry. Gate 3 does not disable svc-enroll: C13–C16 make a S42 hold a defensible proposal, C17 authorizes it and C18/C19 provide limited execution/effect observations. Gate 4 uses C20's verified q-144 join and C22/C23's unapproved configuration findings while preserving actor uncertainty. Gate 5 rejects C27's failed audit criterion, accepts the isolated C28 rehearsal and then uses C29/C30's separate production and owner-acceptance receipts. Gate 6 drafts, but does not send, messages while C31–C33 leave external delivery unresolved.

Variant V10 is a separate fictional negative control: an alert names the shared account, but a service-owner read-only check finds the questioned slot correct; the job manifest includes the exact request under an approved change, and there is no unexpected task or data signal in the supplied scope. Under P1, the analyst still records the alert and sources, but the containment branch has no current harm path and should not execute a disruptive change. A supervisor may downgrade or close only after applying the organization's actual criteria and documenting the limited source scope. V10 cannot be imported as evidence that the main CTN case was harmless.

Variant V10b tests an unavailable approver. The service owner does not answer before a stated log expiry. P1 permits the analyst to request a bounded preservation path from the authorized custodian and invoke the real escalation procedure. It does not let the analyst invent approval for an account disablement. The dry-run outcome is “decision pending; preservation escalated; disruptive action not executed.” If an organization cannot identify a reachable alternate, that is a readiness defect to assign and exercise, not a reason to hide the gap in the playbook.

10.4 Score the playbook as a document, then test it

Use six 0–2 criteria. 0 means absent or contradicted; 1 means present but too vague for a second responder; 2 means the condition, owner and artifact are explicit enough to test. The criteria are: (1) trigger and bounded scope, (2) roles and approvals, (3) source/provenance and uncertainty, (4) containment verification and rollback, (5) recovery acceptance with failed-test handling, and (6) audience-specific communication and next review. This scores document quality, not whether CTN's real controls work. The score must be supported by line references or a dry-run artifact.

P0 earns 1/12 in this classroom rubric: it names a portal-load check, worth 1 under recovery because an observable condition exists, but omits authoritative data, audit and stop criteria; the other five areas lack a usable gate or actively contradict a safe boundary. P1's written gates specify all six areas, so it can earn 12/12 for designed fields. That does not mean it is release-ready. A reviewer should still test it on the main case, V10 and V10b, inspect whether another reader makes the same decisions, and obtain technical, service-owner, privacy and language review. If a local adaptation fails a branch, retain that failure and revise the version; do not preserve the score by weakening criteria after the fact.

A walk-through record needs inputs released at each stage, the branch chosen, its rationale, the owner who would approve, an expected artifact and a stop rule. An observed case card and a simulated dry-run result must be labeled separately. A good revision log reads: “P1 draft 0.2: added negative-control V10 and unavailable-approver V10b; kept gate 3 non-executable without approval; owner review pending.” A poor log says “fixed incident playbook” without naming which decision changed or how it will be tested.

10.5 Measure outcomes without gaming them

Playbook metrics should include a denominator and a quality condition. “Time to first action” can reward unsafe disruption. More useful classroom measures are: time from C08 expiry warning to an authorized bounded preservation request; share of action records with target/approver/expiry/verification filled; share of evidence packages with raw and normalized times; number of recovery tests stopped when a mandatory criterion failed; and time from service acceptance to an assigned improvement ticket. A metric does not replace review of the actual artifact. A one-minute response that disabled all accounts without permission is worse than a slower, bounded decision.

For CTN, the response record could track the C08-to-C09 sequence, C17/C21 approval and expiry, C27 no-go, C29/C30 acceptance, and C33 privacy uncertainty. It must also track failures: C01 lacked after-hours alternates, C09 lacked original-object metadata, C12's self-reported tag misled the early hypothesis, and the first isolated restore lacked an audit actor. Assign each improvement to an owner, due date and falsifiable re-test. Those are future work items, not repaired controls merely because they appear in a table.

10.6 A playbook is a decision interface, not a command transcript

The defective specimen P0 says, in essence, respond to any sign-in alert by disabling a shared account, restoring the latest backup, checking whether the portal loads, emailing a breach notice and closing the incident. It looks efficient because it hides the questions an operator must answer: whether the alert affects the business, what an account supports, what permission exists, whether backup data are correct, what the service test covers and whether any data exposure is established.

A deployable playbook should instead act as a decision interface between evidence, accountable owners and operational procedures. It can prescribe how to ask and document questions without granting action rights. A separate operator runbook, reviewed for the real architecture and authorization, may eventually define safe commands. The classroom P1 is not that operator runbook. This distinction protects a novice from treating a generic text example as permission to disconnect production accounts or send notifications.

Treat each gate as a typed contract with these fields: entry condition; required evidence; permitted analyst output; decision owner; approval boundary; operator if applicable; pass/fail/unknown branch; stop/escalate condition; emitted case artifact; next checkpoint. The words unknown, unavailable and not authorized must be first-class branch values. If the only outputs are “yes” and “proceed,” the playbook will eventually force an unsafe decision when inputs are missing.

This design is aligned in spirit with NIST SP 800-61 Revision 3, which integrates response with organizational cyber-risk management. The CTN gate fields are original teaching choices and should not be represented as mandatory clauses from that publication.

10.7 Seven gates as a controlled workflow

A usable P1 design supports the following seven gates, numbered 0–6, without inventing an eighth stage or changing the existing specimen's scope.

Lesson table; scroll horizontally to read all columns →

This is intentionally not a rigid chronological claim that a service cannot preserve evidence before an incident lead assigns severity. Some gates may be revisited as new evidence arrives. But revisiting does not make an earlier authority grant larger: C21's extension is a new permission event, not a retrospective reinterpretation of C17. Gate dependencies should be explicit. A cause hypothesis does not itself authorize account disablement, and an isolated recovery pass does not imply production approval.

The P1 record should include a source horizon for every branch. At 09:14, the team can discuss initial priority and C08 retention; at 09:35 it has C13–C16; at 09:42 it has C17–C19; at 09:54 it can discuss C20–C23; at 10:16 it can reject C27; at 10:45 it can recognize C30's limited acceptance; at 11:00 it has C31–C33's bounded data question. A second reader should be able to reconstruct the decision without looking at cards not yet released.

10.8 Test inputs must be selected to reveal wrong branches

A walk-through that tests only the main CTN case is inadequate. Because the main case includes a confirmed stored-state problem, a flawed playbook may appear useful even if it would unnecessarily disrupt a harmless alert. Negative controls expose whether the procedure can do less when evidence justifies less.

Main CTN branch: C13 confirms the S42 state discrepancy; C14/C15 narrow approval and job-origin claims; Gate 3 proposes a scoped hold. C17 approves it, C18 reports it enabled and C19 shows one observed route behavior. Gate 4 accepts C20's verified q-144 mechanism without naming a human; C22/C23 leave separate identity questions. Gate 5 refuses C27 after the blank audit actor and then recognizes C28 only as an isolated candidate pass; C29/C30 supply later, distinct production and limited acceptance records. Gate 6 prepares, but does not send, status drafts while C31–C33 remain uncertain about external delivery.

V10 negative control: A separate alert names the shared account, but the owner-approved read-only slot state is correct, an approved run manifest includes the exact questioned request, and no unexpected task or data signal is present in the supplied scope. The correct branch is bounded documentation and review, not account disablement, restore or breach notice. A supervisor may determine whether downgrade or closure is appropriate under the real criteria. This variant cannot disprove the actual main case because it is a different evidence set.

V10b missing-approver test: The relevant owner is unavailable while an authorized source faces a stated retention limit. The correct result is an authorized preservation escalation and a pending disruptive decision. The analyst must not make “emergency” mean “approval invented by the playbook.” A readiness defect should be recorded if there is no reachable alternate. The test succeeds when the procedure safely stops despite pressure to make progress.

These branches challenge three different failure modes: incorrectly treating harm as universal, incorrectly treating harmlessness as impossible, and incorrectly treating missing authority as permission. An assessor should not report “the playbook handled three incidents.” It handled one fictional main case and two separate hypothetical tests. The purpose is decision validation, not an operational case count.

10.9 Separate approval, execution and independent verification in the data model

A common documentation anti-pattern is a single “completed” field shared by the approver, operator and reviewer. That field has no stable meaning. Instead record an approval object with approver, scope, issue time and expiry; an execution object with operator, target version, time and error/receipt; and a verification object with independent observer, source, query/route coverage and verdict. All three carry a reference to the case and action ID. If a step has not occurred, its object is pending, not filled with anticipated success.

For CTN, the P1 implementation might show C17 as approval, C18 as reported execution and C19 as one-route observation. It must not collapse them to “S42 completely blocked.” At C21 an approval extension and a separate operator receipt update the allowed time, not every other permission field. At C24 the task-only disablement is distinct from the C25 later identity action. These are natural examples for a state-machine review: no transition to “verified” without an observation; no transition to “executed” without the required authority; no silent extension at expiry.

Quality assurance should include stale-input tests. What happens when the state read is older than the proposed change? What if the service owner changes the approved target? What if an evidence source expires before the custodian replies? What if the alleged negative control contains a hidden unexplained request not represented in its approved manifest? The playbook should route each inconsistency to a bounded new question and stop the relevant action. It should not hardcode that a task name or account label alone is suspicious enough to disable an identity.

10.10 Document scoring is not release certification

This book's six criteria use 0 for absent or contradicted, 1 for vague but recognizable and 2 for explicit, testable condition/owner/artifact: (1) trigger and bounded scope, (2) roles and approvals, (3) source provenance and uncertainty, (4) containment verification and rollback, (5) recovery acceptance and failed-test handling, and (6) audience-specific communications and review.

P0 earns 1/12 in the existing worked assessment: its generic “portal loads” supplies only a vague observable recovery condition worth 1; the other fields are unusable or unsafe. The P1 document design can score 12/12 because the seven gates express those conditions. Neither result says that P1 operated safely on any real system. The scorer should attach evidence from the actual text, not negotiate points to make a preferred draft look publishable.

A separate operational readiness gate is still required. Before live adoption, a real owner must verify contacts and delegation, retention procedures, architecture-specific route coverage, approved tools, simulation outcomes, accessibility, security/privacy review and change control. A high score with no owner approval is still draft. The CISA federal cyber incident and vulnerability response playbooks illustrate why documented coordination paths matter; they were written for federal civilian systems, and local adaptation requires scope and rights review.

Metrics are equally vulnerable to gaming. “Time to first action” might reward immediate unauthorized account disablement; “time to close” might reward avoiding questions. Prefer measurements whose numerators and denominators encourage auditable decisions, for example: number of approved disruptive actions with complete target/expiry/rollback fields divided by all disruptive actions performed; percentage of recovery candidates correctly stopped on a mandatory failure; and number of privacy-sensitive drafts dispatched without designated approval (target zero). Record sampling window and exclusions. A denominator of zero should be reported as not applicable, not “100% compliance.”

10.11 Worked good and bad release reasoning

Defensible P1 draft 0.2 note: “Replaced P0's automatic shared-account disable, latest-backup restore and unsupported breach message with seven evidence- and authority-gated decisions. Walked the main CTN cards only at their release checkpoints; stopped C27's failed audit gate; and kept C28 isolated from C29 production approval. V10 produced no disruptive action on an owner-confirmed harmless path; V10b escalated bounded evidence preservation without inventing an approver. Remaining before release: real owner delegation and technical route tests, privacy/communications approval mapping, and a witnessed simulation with retained results. Status: training draft, not for production.” This describes work performed without claiming the playbook passed field validation.

Incorrect note: “P1 scored 12/12, fixed incident response and has been deployed. Any unavailable owner can be bypassed for urgent actions.” It confuses written-field coverage with demonstrated operations, overrides the permission boundary precisely where the V10b test demands restraint, and asserts deployment absent any case receipt. It also avoids the uncomfortable result that a valid operational response sometimes consists of not acting disruptively.

10.12 Offline laboratory: rubric score and branch conditions

Goal: verify the classroom P0 score and that a missing approver or absent harm cannot result in a disruptive action in a tiny decision model. Inputs: six P0 criterion scores and three isolated branch tuples. Safety: standard Python 3 only, no network, no file access, no real response commands. Success: output exactly matches the lines below, and the learner explains that a branch result is a recommendation state, not a record of execution.

criteria = [0, 0, 0, 0, 1, 0]
print("C10 P0 points=", sum(criteria))
branches = [
    ("CTN", True, True),
    ("V10", True, False),
    ("V10b", False, True),
]
for branch, authority, harm in branches:
    decision = (
        "PROPOSE-AND-VERIFY" if authority and harm
        else "NO-DISRUPTION" if not harm
        else "ESCALATE-NO-EXECUTION"
    )
    print("C10", branch, "=" + decision)

Executed output:

C10 P0 points= 1
C10 CTN =PROPOSE-AND-VERIFY
C10 V10 =NO-DISRUPTION
C10 V10b =ESCALATE-NO-EXECUTION

The CTN authority=True fixture represents a deliberately simplified point after relevant approval, not permission at the 09:35 proposal checkpoint. PROPOSE-AND-VERIFY does not execute anything. The toy boolean harm field discards evidence strength, impact and scope; therefore this model cannot replace the seven-gate record. Its value is to fail visibly on two unsafe shortcuts. A stronger classroom test would inject an expired approval and an unverified route; both should leave action pending until a fresh owner decision. These are proposed test cases, not reported CTN outcomes.

10.13 Engineer a playbook as a versioned decision contract

A playbook is not the record of a command that ran. It is an interface that receives source-bounded inputs and directs a responsible person to a documented next decision. Its minimum useful behavior is to make uncertainty actionable without granting powers to the analyst. P0's imperatives—disable, restore, email, close—are dangerous because they implicitly assume account compromise, permission, backup correctness, privacy determination and service acceptance. P1 improves structure by defining seven gates, numbered 0 through 6. But a document that names gates can still fail at runtime, so the quality review must separate design coverage, dry-run decision quality and real-world execution evidence.

Each gate can be written as a contract with these fields: entry evidence and release cutoff; decision question; required producer/custodian; permissible analyst output; approver and scope; operator receipt if an action occurs; independent protection and legitimate-service verification; failure/unknown branch; next reviewer and deadline. An implementation that encodes only "true/false" loses critical distinctions. If a data source is not retrieved, the result is UNKNOWN, not FALSE. If an action is approved but no operator receipt exists, the result is APPROVED_NOT_EXECUTED, not DONE. If an isolated recovery test passes, the production gate remains pending. If a message draft is approved but not dispatched, the audience still has not been shown that message.

The NIST SP 800-184 recovery guide addresses planning, exercises and improvement. NIST SP 800-84, published in 2006, provides a framework for exercise design and evaluation. Neither prescribes P1's seven gates, a score of 12/12 or any CTN role/receipt. These are OpenCyber Academy teaching constructs and must be adapted to actual owner authority before any use.

10.14 Exercise branch coverage must challenge the unsafe option

A branch test is an input deliberately chosen to reveal whether a decision interface chooses the wrong action. Testing only the main CTN incident could produce misleading confidence: because S42 truly differs from its owner-approved target, even a crude playbook that always shuts down accounts might appear to have acted in response to harm. The negative V10 branch demonstrates the need for safe non-disruption when an approved run explains a correct slot state. V10b, where the service owner cannot be reached during an evidence-retention warning, tests a different failure: whether an unavailable approval is wrongly treated as emergency permission. The correct outcome is to escalate the authorized preservation question and keep the disruptive operation pending.

Two contrasted worked paths:

Correct path: At C02 the analyst opens a case without declaring account compromise; at C08 the analyst requests narrowly scoped IdP preservation under the proper custodian. At C13–C16 the team proposes an S42-only hold; C17, C18 and C19 separately record approval, reported configuration and one route test. At C20 the job-to-request mechanism strengthens while actor remains unknown. C27 fails the predeclared audit gate; C28 passes only isolation; C29 adds new production approval/action; C30 supplies limited acceptance. C31–C33 open a separate data inquiry and leave public messages unsent. A reliable playbook can stop between any two steps and tell a receiving operator which receipt is absent.

Incorrect path: The analyst sees V10's shared-account alert, runs a disablement action despite its owner-approved benign run, restores a backup despite correct current state, and announces a breach. Here the control has no supported harmful path and its collateral business cost is unjustified. If an approver is absent as in V10b, a blind escalation from "not reachable" to "automatically authorized" is an even clearer failure. The repaired P1 process must protect against action when action is unwarranted, not merely direct faster action in an incident.

10.15 Design measurable quality without confusing it with release approval

P0's 1/12 and P1's 12/12 count the six written-field dimensions in the published classroom rubric. They do not count real disabled sessions, timely custodians, safe restores or delivered communications. A document can achieve 12/12 with no single operational test executed. Therefore release assessment requires independent blind review of a frozen version and three scenario packets: main CTN, V10 non-disruption and V10b missing approver. The evaluator records the requested gate, expected decision, actual trainee output, failed fields, permitted next action, and an owner decision on revision. A design score cannot overrule an unsafe branch.

For a future program metric, define numerator, denominator, source and failure rule. "Percent of approvals documented" should count eligible proposed actions, not all incidents; a missing approval or wrong scope must count as failed rather than disappear from the denominator. "Percent of recovery tests passing" should include C27's no-go in the run population, not just successful C28. "Communication timeliness" should distinguish a draft produced before 12:00 from a message actually approved and sent. Avoid counting hypothetical V10/V10b actions as incidents resolved.

A revision is traceable when it names version, exact changed gate, reason for change, new test and reviewer. A new revision should not erase the previous failure. A source-card release must be frozen for each evaluated decision: C20 may improve Gate 4 after 09:46 but cannot be cited to justify a 09:35 proposal; C33 at 11:00 cannot be cited in C30's earlier service acceptance. This is why a professional playbook needs both a case-record schema and a facilitator release log.

10.16 Offline laboratory C10X — document score versus safe branch execution

Environment: Python 3 standard library, in memory. The invented Boolean fields are not authenticated decision receipts, and this program cannot deploy controls or send communications. The same rubric can score design and still require separate authority and evidence gates for a branch.

SCORES = {
    "P0": (0, 0, 0, 0, 1, 0),
    "P1": (2, 2, 2, 2, 2, 2),
}

def assess10(name, approval, receipt, data, audit):
    if receipt and not approval:
        return "INVALID_UNAPPROVED_EXECUTION"
    if name == "V10":
        return "INVALID_BENIGN_EXECUTION" if receipt else "DOCUMENT_REVIEW_NO_DISRUPTION"
    if not approval:
        return "HOLD_AUTHORITY"
    if not receipt:
        return "APPROVED_NOT_EXECUTED"
    if data is not True:
        return "NO_GO_DATA"
    if audit is not True:
        return "NO_GO_AUDIT"
    return "BOUNDED_CHECK_REVIEW_OPEN"

for name, values in SCORES.items():
    print(name + ": " + str(sum(values)) + "/12")

CASES = [
    ("V10", False, False, None, None),
    ("V10b", False, False, None, None),
    ("C17", True, False, None, None),
    ("C27", True, True, True, False),
    ("C28_ISOLATED", True, False, True, True),
    ("C30_DECLARED", True, True, True, True),
]
for name, *fields in CASES:
    print(name + ": " + assess10(name, *fields))
print("V10_FALSE_NEGATIVE: " + assess10("V10", True, True, True, True))
print("V10B_UNAPPROVED_ACTION: " + assess10("V10b", False, True, True, True))

Literal tested output:

P0: 1/12
P1: 12/12
V10: DOCUMENT_REVIEW_NO_DISRUPTION
V10b: HOLD_AUTHORITY
C17: APPROVED_NOT_EXECUTED
C27: NO_GO_AUDIT
C28_ISOLATED: APPROVED_NOT_EXECUTED
C30_DECLARED: BOUNDED_CHECK_REVIEW_OPEN
V10_FALSE_NEGATIVE: INVALID_BENIGN_EXECUTION
V10B_UNAPPROVED_ACTION: INVALID_UNAPPROVED_EXECUTION

Adversarial interpretation: P1 can score 12/12 while V10b still blocks disruptive action. C27's failed actor audit cannot be averaged away by correct data. C28_ISOLATED reports a favorable isolated test but no production execution receipt. C30_DECLARED is a toy consistency result for a limited accepted scope, not proof that a production system passed every test or that the incident is closed. The V10 hardcoded branch represents only the separate provided benign fixture; no user should build production approval logic from this toy string.

Supervised practice: Freeze P1 as draft 0.2 and write seven gate contracts, each with an unknown/stop branch. Evaluate main CTN, V10 and V10b in separate packets; record why the same input fields could support different operational choices. Run the exact C10X program, then ask a peer to challenge C27/C28 status and the unverified source semantics. Seven-point rubric: two for correct document scoring and its limits, two for main/negative branch distinction, one for approval-vs-execution, one for audit no-go and one for a versioned, owner-assigned retest. A real tenant action or learner-facing dispatch is forbidden.

Additional adversarial control and release rule: The added V10_FALSE_NEGATIVE row inserts a fictitious reported execution into the normally benign V10 branch. A playbook that answers DOCUMENT_REVIEW_NO_DISRUPTION despite such a report would mask potentially unauthorized action; the corrected classifier rejects it. V10B_UNAPPROVED_ACTION supplies a reported action without any permitted approver and rejects it before treating the case as an ordinary escalation. These are synthetic contradictions, not new CTN actions. The previous eight output lines remain unchanged. This toy guard does not authenticate the approval, prove that a control actually ran, or replace the chapter's seven-gate contract. A reviewer should preserve both the unexpected action report and the source/authority evidence that would be required to investigate it.

10.17 Synthesis and next chapter

The repaired playbook is stronger because it makes authority, source limits, accepted business state, failed tests and unknowns visible to a second responder. It is not an executable runbook. The next chapter's staged tabletop can measure whether a supervised learner actually follows the gates under time pressure, including when a source or approver is unavailable; success in a toy decision function is not operational readiness or an accredited qualification.

At each gate, a second responder should be able to tell who may approve and which evidence is still missing.

Common errors and limits

• Treating a high playbook-document score as proof of technical effectiveness or accreditation.
• Building one linear path that cannot stop for absent authority, conflicting evidence or a failed recovery test.
• Copying P0's unsupported “breach” notice into the public branch just because a data-related card arrived.
• Reusing a source-linked third-party playbook under this book's CC0 dedication without a rights review.
• Closing a case when the portal loads while data, identity, audit or communications questions remain assigned.

Practice: peer walkthrough and release decision

Give a second learner P1, the main case up to 09:14, then release later cards at their checkpoints. Require an actual filled gate record; the reviewer cannot use the answer appendix during the first pass. Repeat with V10 and V10b. Compare branch decisions against the preannounced rubric, record disagreements, revise P1 to draft 0.2, and list the approvals and technical tests still needed before any real operational adoption. This is a tabletop of text, not an exercise in a production tenant.

Exercises — subject 10

EX046 — Defect inventory. Input: P0 and C13–C33. Name at least six distinct defects, each with the case card or learning gate it would violate and the likely harm. A 2-point result separates a missing approval from an incorrect backup target and an unsupported public notice.

EX047 — Playbook rewrite. Input: P0 and P1. Produce a one-page seven-gate local draft (gates 0–6) with trigger, minimal evidence, approval/stop rule, result artifact and owner per gate. A 2-point result keeps it a supervised decision aid, not a command sequence or permission grant.

EX048 — Three-branch walkthrough. Inputs: main CTN case through C33 and separate V10/V10b. Produce a three-row branch table: evidence, action status, approval gate, stopping or review condition. A 2-point result applies V10 only to its variant and does not execute a disruption under V10b. Compare your branch table to the C10 recommendation-state fixture in §10.12; do not treat its output as execution evidence.

EX049 — Quality score. Input: P0, P1 and the six criteria in §10.4. Score each criterion 0–2 for both drafts, cite the text that earns points, and explain why 12/12 document design would still require field testing and review. A 2-point result reproduces P0's 1/12 and distinguishes design from operational proof. Reproduce the C10 four-line offline output and explain why the P0 point count and toy branch results cannot certify a field-ready playbook.

EX050 — Versioned release note. Input: EX046–EX049. Write a 100–160-word draft 0.2 release note for future Chapter 11 simulation, including three tested branches, two remaining approvals or technical checks, one owner-assigned improvement and an explicit “not for production” status. A 2-point result does not mark the book or playbook complete.

Subject synthesis and next step

Ten sequential subjects now teach a supervised response path: prepare ownership, make bounded decisions, triage and preserve evidence, investigate alternatives, contain an observed harm path, test a cause-related change, restore correct service, communicate honestly and review the playbook itself. Chapters 11–12 use these artifacts in a supervised simulation and case portfolio. The full book still needs deeper teaching, independent review and 300-page A4 verification.