Chapter 04 — Guided incident simulation and after-action review

Chapter 04 — Guided incident simulation and after-action review

Five daily lessons · week 4 of four. This chapter groups the original section identifiers 4.x. Lesson numbers identify a learner day; section identifiers remain stable so existing source references and laboratory instructions still work.

Module map

Module 4 overview: five daily lessons below provide the teaching, examples, exercises and worked-answer links.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Exercise purpose and boundaries"]
  N2["4.2 Release the injects in order"]
  N3["4.3 Worked tabletop: one acceptable path"]
  N4["4.4 Run a reproducible handoff drill"]
  N5["4.5 Score the evidence and the handoff"]
  N6["4.6 After-action review"]
  N7["4.7 What this exercise can measure"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX048"]

Module logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Exercise purpose and boundaries"]
  N2["4.2 Release the injects in order"]
  N3["4.3 Worked tabletop: one acceptable path"]
  N4["4.4 Run a reproducible handoff drill"]
  N5["4.5 Score the evidence and the handoff"]
  N6["4.6 After-action review"]
  N7["4.7 What this exercise can measure"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX048"]

[Learning outcomes]
    |
    v
[4.1 Exercise purpose and boundaries]
    |
    v
[4.2 Release the injects in order]
    |
    v
[4.3 Worked tabletop: one acceptable path]
    |
    v
[4.4 Run a reproducible handoff drill]
    |
    v
[4.5 Score the evidence and the handoff]
    |
    v
[4.6 After-action review]
    |
    v
[4.7 What this exercise can measure]
    |
    v
[Worked example] --> [Exercise EX048]

Module learning outcomes

Across these five daily lessons, a learner should be able to:

1. Run a contained response exercise from initial alert through an owner-approved service decision.
2. Produce a case record that separates observations, hypotheses, approvals, actions and results.
3. Test a return-to-service claim against explicit evidence instead of accepting a dashboard status.
4. Give a short, accurate internal update that protects people from premature attribution.
5. Identify a process gap, assign an owner and define a measurable improvement check.
6. Draft audience-specific, versioned status messages that separate operational coordination from an unverified exposure report and any formal notification decision.
7. Calibrate a tabletop score against frozen artifacts, resolve reviewer disagreement with evidence and propose a revision without changing the earlier decision record.

Module 4 exercise rules

Use the four rounds and choose either Branch S or Branch P for your final decisions. Record event time and card-release round separately. Round A has R1–R8, Round B adds R9–R16, Round C adds R17–R24, and Round D first supplies a branch result and only later P1/C1 and V1. Do not cite a later card to justify an earlier action; do not invent a real export, restore, account action or person behind desk-a. For each answer, submit the named artifact with case ID, source IDs, current round, observation versus proposal or reported action, decision owner, remaining limit and next review. A solo learner may write all roles, but must still record who would approve and who would verify a change.

Numbered-exercise rubric: score 0 for an absent artifact or an unsupported breach, actor, executed action or recovered-service claim; 1 for an artifact that addresses the task but omits a required source, release boundary, authority or verification; 2 for an evidence-linked, authorized and reviewable artifact with every local field below. This is distinct from the six-output tabletop rubric in section 4.5. Each worked result shows one acceptable path; a different branch or conclusion can earn 2 when its assumptions, evidence and constraints are explicit.

Lesson 16 — Release-aware tabletop and scored handoff

Week 4, day 1. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

4.1 Exercise purpose and boundaries

This is a tabletop simulation, not an instruction to touch a real account. It uses the fictional Harbor Library records in Chapters 1–3. Learners may write notes, compare options and role-play approvals. They may not contact a real library or use a production system. A solo learner can fill every role; a group should assign an incident lead, analyst, service owner, recovery lead and communications contact. Each role must identify what it can decide and what needs another owner's approval.

NIST SP 800-84 describes designing, conducting and evaluating IT plan exercises. This course uses that general idea to evaluate reasoning and coordination. The exercise does not test actual organizational readiness, because the people, data, systems and consequences are invented.

Inputs: R1–R24, the service map, a case-note template from Module 1, the decision/collection fields from Chapters 2–3, and the Module 3 P1/C1 and V1 cards when the facilitator releases them. Timebox: four rounds of ten to fifteen minutes, then a twenty-minute review. Outputs: one case timeline, one hypothesis table, one approved-action record, one recovery test plan, one internal status message and one improvement ticket. Each output may fit on one page; completeness and reasoning matter more than length.

4.2 Release the injects in order

The facilitator should not reveal later records early. In a solo session, cover the later rows until each round is complete. If a learner chooses a different defensible action than the worked example, continue with the corresponding branch and state the assumptions rather than forcing the reference answer.

Branch S: session revocation. At 09:45 UTC, the identity administrator reports that the current desk-a session was revoked under the fictional incident lead's approval. A narrow booking query shows no later edits in its queried range. The staff member must sign in again. B19 still shows an incorrect room until an owner-approved correction is made. This branch does not establish who used the prior session or that another access path is absent.

Branch P: staff-write pause. At 09:45 UTC, the service owner reports that staff writes were paused for fifteen minutes under the fictional approval. The manual queue has two pending booking requests. The booking audit shows no writes in the pause interval, but the cause of B19 and B20 remains unresolved. This branch does not prove the account is safe when writes resume.

For either branch, R23 still says the last documented restore test was thirty days earlier. After discussing the branch result, reveal P1/C1 and then V1 as later exercise cards. P1/C1 shows two booking mismatches that require owner-reviewed correction; V1's isolated-copy test supports the two tested access claims but fails actor attribution in the test audit. Neither card proves that production corrections ran. The recovery lead should propose an isolated check of the booking state and a narrow audit check before declaring normal service. The privacy contact should review any new evidence of personal-data access; R24 alone is not clearance.

4.3 Worked tabletop: one acceptable path

Round A. The learner opens HL-IR-001, notes that R1 precedes booking edits, names the service owner as pending, records compromise as a hypothesis and asks whether the edits were training work. Round B. R9–R16 add an unexplained B19 edit and a time-sensitive source-preservation risk; R15 states a 24-hour duration without its deletion-clock anchor, so an exact deadline is unknown. In this worked path the analyst proposes a bounded preservation request for the application custodian. A separately recorded classroom approval may authorize the request, but neither approval nor request establishes that a source hold or collection occurred. Set a 09:35 review to check receipt and expiry semantics. Round C. R17–R18 add an unplanned B20 edit. The analyst proposes narrow session revocation; the lead and identity owner are the required approvers and may record a separate classroom role-play decision, not a supplied R-series approval. Without that decision receipt, approval is pending. The service owner stands by for a separate short write-pause decision if edits continue. Round D. Branch S reports the revocation and no later edits in a limited query. P1/C1 then reveals that B19 and B20 are still inconsistent with the approved target. V1's isolated-copy trial has a blank audit actor field. The learner requests owner-approved correction, a bounded restore test and audit remediation, keeps the cause unresolved, and proposes restricted or explicitly approved limited operation with monitoring rather than closing the case.

This is one acceptable path. A team that prefers Branch P can pass if it explains the service cost, establishes approval, plans for the two queued requests and states how it will decide when writes may resume. In either path the later P1/C1 and V1 cards prevent an unsupported “fully recovered” conclusion. The exercise assesses decision quality under incomplete information, not agreement with a preselected action.

4.4 Run a reproducible handoff drill

The facilitator or solo learner should keep a release ledger with three columns: time the fictional event occurred, time the learner received the card and the round in which the card became usable. For example, R9 describes an edit at 09:03 UTC but enters the learner's evidence set only in Round B; P1 describes an owner target at 09:40 and belongs to Round D, after the 09:37 containment proposal. This prevents a polished final answer from quietly using later evidence to justify an earlier decision. The ledger can be written in Markdown alongside the case note and should retain the original record IDs.

At each round, freeze a one-paragraph state snapshot before revealing the next card. It should contain (a) what is observed, (b) the current leading and alternative hypotheses, (c) a proposed action or reason to wait, (d) the owner whose approval is required, and (e) a time or event that will trigger review. A learner may revise a hypothesis as new records appear but should leave the earlier snapshot visible. Revisions show how the decision changed; replacing earlier text with hindsight hides a real response skill.

Receipt and release contract: Supplied R1–R24 records are immutable case cards, distinct from learner/facilitator role-play. At 09:37, they justify a proposal only: no incident-specific revocation approval, deployment or effect receipt has been supplied. A role-play decision such as C-approval-v1 must separately name the exact target, approving roles, time, scope, duration and observer; if it is not performed and recorded, approved = pending. Approval never authenticates execution. Branch S/P arrives only after the Round C snapshot and cannot repair a missing earlier receipt. A source-preservation request requires its own dispatch and custodian receipt; an effective source hold and a collected case copy each require further, independent evidence. Neither a positive acknowledgement nor a request creates a copy. Keep each status proposed / approved / executed / verified independently visible.

At Round D, write a claim ledger before an internal update. A sample for Branch S is:

This ledger separates supported, contradicted and untested claims. “No later edit appeared” is supported only for the branch's queried range. A missing actor field is an observed failed criterion, not simply an unknown. Those two states call for different follow-ups: broaden an authorized query for the former, repair and retest the audit for the latter.

The handoff must reach a person who was not in the tabletop. Give that person the case ID, last evidence snapshot, chosen branch, approvers, action actually reported by the branch card, checks that passed or failed, access location for the restricted synthetic artifacts, owner of each open item and the next checkpoint. The receiver should be able to answer, without guessing, whether staff writes are currently paused and who may change that status. If a real handoff omitted those two facts, it could cause both unnecessary outage and an unsafe restart.

Failure inject for review, not for the live round: suppose a team reports “all bookings correct” after seeing only the V1 access test. Ask which supplied card tests that sentence. V1 does not compare booking states; C1 contradicts the sentence for B19 and B20. A defensible revision is: “The isolated-copy access checks passed, while B19 and B20 remain pending owner-approved correction and the audit actor field failed its test.” This exercise in claim repair is as important as selecting the initial containment action.

4.5 Score the evidence and the handoff

Use this simple rubric for each of the six outputs: 0 = absent or unsupported; 1 = present but incomplete; 2 = specific, evidence-linked, authorized and clear about limits. Maximum score is 12. A passing classroom submission should score at least 9, with no zero for approval or evidence scope. This is an editorial practice rubric, not a credential or formal academic grade.

A learner should also note inaccessible evidence and why it was not collected. Do not award points for inventing device detail, a data breach, an attacker identity or a successful restore that the scenario never supplied.

Calibrate a score against the artifact that existed at the checkpoint

A rubric is useful only if two reviewers can apply it to the same submission, not to what they remember the learner saying later. NIST SP 800-84 describes exercise evaluation against criteria identified before the event. The six-output rubric above and the worked comparison below are original classroom choices. They evaluate a learner's records, not Harbor Library's real readiness.

Freeze each artifact at the end of its round. Give it a version ID such as A-intake-v1, B-hypotheses-v1 or C-action-v1, the release round and the source IDs actually available then. A later D-recovery-v2 may improve the final packet, but it does not rewrite C-action-v1. Store a one-line reason for every revision. This matters because the Branch S report of revocation arrives in Round D; it cannot make a Round C proposal into an action already performed at 09:37.

Consider this invented learner packet L2, prepared after all cards have been released. Its quoted excerpts are student answers in a separate classroom example, not new R-series observations. Two reviewers independently apply the 0–2 rubric before discussing their scores:

1. Six-row timeline — reviewers A/B: 2/2; reconciled: 2. The learner lists R1 08:40/A, R3 08:43/A, R5 08:48/A, R9 09:03/B (received at 09:20), R18 09:24/C and R21 09:29/C, all UTC, and writes: “This order does not identify the human operator.” Source IDs, event versus release times and a causal limit are explicit.
2. Round B hypotheses — reviewers A/B: 2/2; reconciled: 2. The learner writes: “R10 may support planned work; R9 leaves B19 unexplained. Misuse remains possible; R13 lacks device detail. Ask the identity owner for a bounded session association check.” Alternatives, limits and a discriminator are present without using R17.
3. C-action-v1 — reviewers A/B: 2/1; reconciled: 1. The learner writes: “Recommend revoking the current session; identity owner consulted; check again at 09:45.” This records a proposal and review, but “consulted” is not incident-lead approval. Staff cost, fallback and the test interval are missing. Branch S cannot repair this frozen Round C artifact.
4. D-recovery-v1 — reviewers A/B: 1/0; reconciled: 0. The learner writes: “V1 passed, so all bookings are correct and the audit identifies the editor.” C1 contradicts booking correctness for B19/B20, and V1's actor field is blank. The conclusion is unsupported, not merely incomplete.
5. Status — reviewers A/B: 2/2; reconciled: 2. The learner writes: “Branch S reports one session revoked at 09:45; B19/B20 and audit actor remain open. Service owner and audit owner review at 10:05; cause unknown.” The action, open criteria, owners and checkpoint are bounded.
6. Improvement — reviewers A/B: 1/1; reconciled: 1. The learner writes: “Fix the audit actor within 30 days.” A gap and proposed window exist, but no accountable owner, test artifact or interim observation is specified, so closure cannot be checked.

The reconciled sum is 8/12 (2 + 2 + 1 + 0 + 2 + 1). It is below the classroom threshold of 9 and has a zero in recovery evidence, so packet L2 does not pass. Reviewers should record their disagreement rather than average 2 and 1 into 1.5: the rubric permits only 0, 1 or 2. Reviewer A can show a source pointer that satisfies a missing field, or accept Reviewer B's score. Here no such pointer exists. A high total would not excuse an unsupported recovery claim, and a corrected final sentence would not retroactively justify the earlier Round C action.

Reconciled calibration ledger (original frozen submissions):

Two different evidence horizons: L2's status was written after all D cards and is not the same assignment as EX048, whose two-sentence 09:45 update must be frozen after Branch S or P but before P1/C1 and V1. A correct post-all-cards sentence that names V1's missing actor would contaminate EX048. Reject early use of R17 in B or P1 in C even if the later statement proves accurate; repair the subsequent version while retaining the earlier score. An improvement from D-recovery-v1 to D-recovery-v2 earns a new assessment only; it does not rewrite the first 0. A score of 2 in one artifact does not cancel another critical zero.

How to revise L2. In C-action-v2, keep the 09:37 proposal as a proposal; request the incident lead's approval, add the staff reauthentication cost, a fallback if a verified edit continues and a named 09:45 query with source and interval. If a separate fictional approval is later supplied, record when it arrived. In D-recovery-v2, list the P1/C1 comparison as two matches and two mismatches, and mark V1's tested access behavior separately from its failed actor-attribution criterion. Ask the service owner to authorize a correction and the audit owner to fix and retest the field; both remain planned until a result is supplied. In the improvement ticket, name the audit owner, an accepted due date, the interim restricted comparison and a controlled edit whose actor and UTC time a second reviewer can verify. The revised packet can earn a new score when its fields are actually present. It still cannot prove live-system containment or recovery.

Practice check: score the six L2 excerpts yourself before reading the reconciled column. For each disagreement, point to the missing or contradicting record and decide whether the correct label is absent/unsupported, incomplete or evidence-linked and bounded. Then write three one-sentence revision requests for the action, recovery and improvement artifacts. The worked comparison above supplies the target scores and the paragraph above supplies acceptable revisions; EX050 asks you to perform the same calibration on your own final handoff. No production system or real personal record is needed.

Worked checkpoint

At an early exercise checkpoint, score only the cards actually released and the learner artifact frozen at that time. A later worked solution may teach a better answer; it cannot retroactively improve the earlier artifact score.

Practice — Lesson 16

EX039 — Role and scope card

Objective: assign authority before observing the case outcome. Inputs: Round A, Module 1's role table and synthetic R1–R8. Output: a five-row role card for incident lead, analyst, service owner, recovery lead and communications contact; name each responsibility, one approval or escalation boundary and one verifiable output. Add a single sentence defining permitted objects, actions and exclusions. A score of 2 makes clear that neither a learner nor analyst can independently disrupt a real booking service.

DEL4 extension: In the same five-row card, add the role responsible for receiving and acknowledging each critical update. For one role, give the message ID/version and an expected read-back question. Keep an unknown alternate unknown; do not invent a working channel.

Worked answer: EX039 in the final appendix.

EX040 — Intake artifact

Objective: produce a reproducible first handoff without hindsight. Inputs: Round A only, R1–R8 and the 09:00 case-open time. Output: exactly four labeled lines covering case/time/service, at least two observed source events, current status and unknowns, and the owner question plus proposed 09:05 checkpoint. Cite record IDs and mark R5 as a patron report. A score of 2 does not cite R9, R17 or a later branch result and does not treat proposed preservation as already performed.

Worked answer: EX040 in the final appendix.

EX041 — Evidence chronology

Objective: separate source-event time from learner availability. Inputs: R1–R24 after Round C; no Round D card. Output: a six-row table with ID, UTC event time, source, release round and observation, using at least one item from each of Rounds A, B and C. Add one ordering fact and one causal or identity claim that the sequence cannot prove. A score of 2 retains that R9's 09:03 event reached the learner only in Round B, while R17–R18 could not guide the 09:20 decision.

Worked answer: EX041 in the final appendix.

EX042 — Competing explanations

Objective: maintain discriminating hypotheses at the 09:20 review. Inputs: R1–R16 only. Output: three rows for authorized training, unauthorized use of desk-a and display/state divergence, each with supporting record, contrary or limiting record, narrow authorized check and a result that would weaken it. Do not use R17–R18 or P1/C1; those arrive later. A score of 2 says B19 is unresolved rather than proving one explanation from the account label or a patron report.

Worked answer: EX042 in the final appendix.

Continue studying — lesson 16 of at least 20

← Lesson 15 · Course lesson index · Lesson 17 →

Continue to the next authored daily lesson.

Lesson 17 — After-action review and unavailable-approver branch

Week 4, day 2. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

4.6 After-action review

Close the tabletop with three questions: What helped us decide? What slowed us down? What will we change and how will we check it? Separate a one-time case correction from a reusable program improvement. For example, correcting B19 and B20 fixes two bookings; naming the booking service owner and rehearsing the approval path improves readiness for the next event. A good improvement ticket has an owner, a deadline and an observable test.

For this case, the team can turn the V1 audit failure into a testable improvement: assign the application and audit owner to find why the synthetic change lacks an actor identifier; require a new controlled test that produces the correct actor and UTC time; and have the response lead review the evidence before retiring any compensating monitoring. The ticket should also state what staff should do while attribution is incomplete. This is a program control improvement, distinct from correcting individual bookings. Another ticket could require the recovery lead to repeat an isolated restore and record its duration, source timestamp and booking comparison. An empty “review backups” task is not measurable.

The team should not call the case “resolved” merely because the tabletop ends. In the fictional facts, identity attribution and root cause remain open. The course ends when the learner can hand off that uncertainty safely, describe what evidence would close it and show how the organization will review its response process.

4.7 What this exercise can measure

An exercise can produce an excellent discussion while leaving a technical control untested. NIST SP 800-84, sections 4–6 distinguishes tabletop exercises, functional exercises and tests. Its 2006 examples need local review before use in a contemporary environment; the distinction between talking through a plan and measuring a system remains useful here. The Harbor Library tabletop asks participants to reason from supplied records. It does not contact an identity provider, pause writes or restore a database. Its score is evidence about a learner's reasoning in this classroom, not a measurement of a real organization's recovery capability.

Before the first inject, write a measurement contract: objective, observable participant behavior, evidence to collect, success threshold and a claim the exercise cannot establish. This prevents a facilitator from deciding after the fact that an engaging discussion must have met every objective. The contract below is specific to the fictional case. Its thresholds are OpenCyber Academy classroom choices, not NIST requirements.

The first two rows are primarily process evidence. The last row points toward a separate technical test plan. A useful learner answer names the boundary: “We rehearsed who would request a restore and what its acceptance conditions would be; we did not execute or time a restore.” This sentence can be true even if every participant completed the tabletop successfully. Its honesty makes the next test easier to design.

To turn an untested recovery claim into an authorized test, the recovery lead would need a named isolated environment, a specific approved copy, a measured start and end time, expected booking values, an operator, a verifier and a safe stop rule. A service owner would then compare that test result with an approved business target. If the test failed, the evidence belongs in the improvement plan. If it passed, it would support only the tested copy and configuration; it would not identify the earlier desk-a operator or establish that a later production return would behave identically. The present classroom supplies none of those measured values. R23 is a backup-job statement, and V1 is an isolated-copy access and audit trial with a failed actor field.

An observer must record what participants did, not only what they said they would do. For this discussion exercise, the record is the frozen Round A–D notes, the facilitator's release ledger and the six submitted artifacts. If a participant says “we preserved R9,” but the only artifact is a request with no collected copy, record the request as observed and preservation as unverified. If the facilitator accidentally reveals P1 before Round C, record that deviation: the learner's later containment choice may be informed by evidence that the intended exercise withheld. Do not hide a compromised exercise run behind a high numerical score; repeat the affected decision checkpoint under correct release conditions.

A two-minute review: for each of the six artifacts, draw two columns labeled observed in exercise and requires another test or source. Put the approved-action record in the first column if its fictional approvals are recorded. Put restore time, production audit coverage and a real customer impact measurement in the second. If an item appears in both columns, narrow the claim until the columns no longer conflict. This review is optional practice and is not one of EX039–EX050.

4.8 A worked after-action report and improvement plan

NIST SP 800-84, section 4.5 and Appendix A describes evaluation that records exercise background, observations and recommendations. The following original classroom report applies that general structure to the Harbor Library model path; it is not a copied NIST template and is not a report from an actual organization. It shows a learner how to connect each proposed improvement to an observation and to a later verification activity. In a real exercise, the report author must obtain the actual facilitator notes and participant feedback rather than infer that the model path occurred.

Report identity and boundary. Case HL-IR-001; exercise type: facilitated, discussion-only tabletop; scenario: fictional room-booking edits and uncertain use of desk-a; rounds A–D; model path: Branch S. Participants are roles—incident lead, analyst, service owner, recovery lead, identity administrator and communications contact—rather than named real people. R1–R24, Branch S, P1/C1 and V1 are classroom cards. No production identity action, database correction or customer notice was performed. The report does not estimate actual business loss, compromise probability or restoration duration.

Predeclared objectives. O1: open an evidence-bounded case record by the Round A checkpoint. O2: make a narrow preservation request before the Round C response choice. O3: document the authority and verification plan for a reversible containment action. O4: refuse an unconditional normal-service declaration when the later booking comparison or audit test fails. Each objective has an artifact in section 4.7. The six-output score from section 4.5 supplements, but does not replace, these four objective checks.

Observed model trace. The worked Round A intake cites R1, R3 and R4 and leaves the service-owner answer pending; that supports O1 for this model, not for an unseen student submission. In Round B, the model requests a narrow audit copy before choosing a containment option; R15 makes the retention question urgent, but the record has no collector receipt, so O2 is met as a request and preservation remains unverified. At Round C, the model recommends session revocation, names the fictional incident lead and identity owner as approvers, and leaves service-owner authority for a write pause separate; this supports the decision-record part of O3. Branch S later reports revocation at 09:45, but the query covers only its stated range. A learner who writes “all unauthorized access stopped” would fail the verification portion of O3. In Round D, P1/C1 shows two mismatches and V1's actor field is blank, so the model withholds unconditional recovery; O4 is met for the model path. The model does not supply an actual restore-time measurement.

The table does not claim these improvements have been implemented. A recommendation becomes an assigned action only when a named owner accepts it, a due date is recorded and the acceptance evidence is agreed. In the model's improvement plan, the response lead owns the first follow-up meeting; the service manager owns the contact and authority record; the evidence custodian owns the export receipt procedure; and the application/audit owner owns the V1 attribution investigation. Set dates from an actual exercise calendar. A classroom learner can propose “within 30 days of the tabletop” but must label it a proposed deadline until the fictional owner accepts it.

Independent closure rule. The person who implements a change should supply the test artifact; a different reviewer should decide whether it meets the predeclared criterion. For the audit issue, a configuration change or a filled ticket is not closure. The reviewer needs a controlled edit with the expected test actor and UTC time, a pointer to the resulting log and a statement of the tested scope. A pass in one isolated environment does not automatically cover every production path. If the test fails or the owner cannot produce the artifact, keep the ticket open and keep any approved interim monitoring in place. This is a classroom quality rule for the plan, not a universal legal or regulatory closure standard.

What to report to management. A concise summary can state that the model discussion surfaced a missing initial owner contact, a preservation request without a copy receipt, and two failed recovery acceptance criteria; it can name the proposed owners and next tests. It should also state that no live system was exercised. The report should not say “the incident was contained,” “the backup worked,” “no personal data was affected” or “the cause was found.” Those sentences exceed the supplied cards. The after-action report's function is to guide a better next exercise and test, not to manufacture a resolved case.

4.9 Optional replay lab: the service owner cannot be reached

This separate replay variant starts from the Round C decision point; it does not alter R1–R24 or the reference Branch S/P cards. Keep your original Round C note, then make a fresh copy labeled HL-IR-001-REPLAY-F1. The purpose is to test whether a learner can continue evidence work while withholding an action whose required approver is unavailable. The replay is a discussion only. It does not authorize a real session change, write pause or data collection.

New card F1, revealed at simulated 09:35 UTC: the booking service owner is temporarily unreachable, and the response plan lists no confirmed alternate for approving a staff-write pause. The incident lead and identity owner remain reachable for a narrowly scoped session decision under the fictional rules already stated in section 3.3. R21 still describes the owner's tolerance for a fifteen-minute pause; it does not become an approval because the owner is absent. R17/R18 are available at this Round C point. Branch S/P results, P1/C1 and V1 remain withheld until the ordinary Round D sequence.

Task: write two decision records at 09:37. Record A is a bounded recommendation that the reachable incident lead and identity owner could approve or reject for the current desk-a session. Record B is a proposed staff-write pause marked approval pending, with a reason it might be needed, its service cost, who is being contacted, what evidence can still be reviewed meanwhile and a stop or escalation trigger. Then prepare a one-sentence handoff for the next response lead that says which action, if any, was reported executed at 09:37. No execution card exists at this point, so the answer must say none is reported. The objective is not to force Record A to be approved; a learner may defer it with an explicit risk and review time.

Inputs and authority check: use R17, R18, R21, the option matrix in section 3.3 and the Module 1 role boundary. The incident lead can coordinate an escalation and request a contact check; the identity owner can approve or reject the scoped session action with the incident lead in this fictional exercise. Neither role has been given authority to approve the booking-service write pause alone. The analyst may prepare a reversible option and examine already supplied records; a production audit export would still require its own collection authority and custody record. Do not call a missing reply consent.

Expected artifacts and rubric: submit Records A and B plus the one-sentence handoff. Award one point each for (1) preserving the distinction between R21 tolerance and approval, (2) recording the two reachable approvers and a bounded verification for Record A, (3) leaving Record B pending and documenting the affected queue/service cost, (4) naming an allowed next evidence or escalation step with a review trigger, and (5) stating that no 09:37 execution has been reported. A 5/5 response can choose a different defensible risk tradeoff; it cannot invent an alternate owner, use a later branch result or claim that a write pause was already enacted. A model answer appears after the 50 numbered worked results.

Why replay matters: if two students choose different proposals yet both respect the same approval boundary, the exercise can distinguish justified decisions from lucky outcomes. If F1 changes the decision, compare the original and replay records field by field: which observation changed, which authority became unavailable, which action was held and which review trigger became more urgent? Only the authority fact changed; the underlying R17/R18 evidence did not. That comparison teaches a reusable response habit without treating a fictional facilitator card as real incident evidence.

4.10 Optional communication replay: a request for reassurance and an unverified claim

An incident can have a technically careful case record and still cause harm if its updates promise more than the evidence supports. The operational team may need details about a specific account and booking IDs; patrons need a useful description of the affected service and where to get help. A privacy contact may need the exact origin of a new exposure claim. These audiences do not need identical messages, and an internal coordination note is not automatically a public statement or a formal notification. NIST SP 800-61 Rev. 3, RS.CO and RC.CO discusses incident reporting, coordination and approved recovery communications. The message cards, word limits and scoring rule here are original teaching devices, not prescribed NIST wording or a determination of any notification duty.

This separate after-Round-D replay uses Branch S unless a learner clearly marks a Branch P alternative. The canonical R1–R24, Branch S/P, P1/C1 and V1 retain their meanings. No new card may be used to justify the earlier 09:37 choice. Write only in a local Markdown exercise file; do not send a message to a real person or publish one. The fictional organization has not supplied its legal jurisdictions, contracts, notification thresholds or approved external spokesperson, so the exercise cannot decide that a statutory notice is or is not required. It can identify who must assess that question.

Card M1, released at simulated 09:50 UTC. A front-desk supervisor asks the communications contact: “May we tell patrons that bookings are restored and the problem is over?” The request is a question, not evidence that service has returned. Branch S reports a session revocation at 09:45 and a quiet bounded booking query. P1/C1 still shows B19 and B20 inconsistent with the approved target, while V1's isolated test has a blank actor field. The record has no owner-approved production correction, no full-service acceptance and no production audit pass. A reassuring sentence would be easy to write and hard to defend.

Card M2, released at simulated 09:52 UTC. The communications contact receives a forwarded internal chat sentence: “Someone said the newsletter list was stolen.” It contains no original author, time of alleged access, source system, export record or case reference. It establishes that an unverified statement was received, not that data was accessed or exported. R24, recorded at 09:36, says that no record then established access to the newsletter list or another personal-data store. R24 is not a permanent all-clear; M2 is not proof that R24 was wrong. The privacy contact and incident lead should receive a narrowly framed verification request through the fictional approval route, with the original forwarded item preserved as a report of a claim and its provenance gap stated.

Decide which communication you are drafting

An incident coordination update tells the response roles which action was reported, what test failed, who is doing the next check and when the next decision is due. It can include restricted case identifiers if sent through an approved internal channel. A service status draft gives patrons a useful description of a booking discrepancy and a safe way to check their own booking, without revealing an account label, unsupported root cause or another patron's information. A formal incident or privacy notification is a separate, approval-dependent decision made under applicable procedure by designated roles; the sparse classroom record cannot resolve it. A rumor should be routed for assessment, not quietly appended to a patron message as if verified.

Versioning matters because evidence changes. A 09:37 proposal, a 09:45 reported action and a 09:54 communication draft are three different states. If a team previously sent “all bookings restored,” it should not erase the old version and pretend the assurance was never made. Keep the issued wording, audience, time and approving role; issue a clearly linked correction through the same approved route with the new evidence and a next update. In this exercise there is no issued earlier message. A learner may practice correcting an explicitly hypothetical flawed draft, but must not claim that Harbor Library actually made it public.

Use this small claim-to-message ledger before drafting:

The ledger deliberately distinguishes false or contradicted, unverified, and conditionally useful claims. A sentence may be accurate for one restricted audience but inappropriate in a public draft because it exposes unnecessary operational detail. A status note should tell its reader what to do with the information. “Investigating” alone does not tell a front-desk worker how to handle a disputed booking; “all clear” would be worse. The correct short update states the present limit and the next responsible check.

Practice: produce a versioned communication packet

Write four Markdown artifacts, all marked draft, not sent. First, a five-row claim ledger based on the table above, adding the record or card ID and the earliest round in which each claim became assessable. Second, a restricted 09:54 internal update of 80–120 words for the incident lead, service owner, front-desk supervisor and privacy contact. State what Branch S reported, which booking and audit criteria remain open, the status of M2 and who will check each issue. Give a fictional next review at 10:05 UTC; it is a planned checkpoint, not a guaranteed restoration time.

Third, write a patron-facing holding draft of 45–80 words for approval by the service and communications owners. It may say that the library is reviewing discrepancies affecting room bookings and will provide an update after verification. It should offer a practical contact route only as a proposed, owner-confirmed route. It should not name desk-a, claim that a breach occurred, declare the booking service fully restored or say that no personal data was affected. The student is drafting a possible message, not deciding to publish it.

Fourth, write a privacy assessment request of three to five sentences: identify M2 as an unattributed report, mention R24's earlier limited finding, ask what authorized source or custodian could verify newsletter-list access in a bounded period, and name the incident lead/privacy contact as decision partners. Preserve the forwarded wording only in the restricted exercise record; do not copy a real person's message. If the result later supports a breach, route notification assessment to designated decision makers under the organization's actual procedure. If the result does not, record the tested scope and residual gaps rather than announcing universal absence of exposure.

Branch P variation: replace the Branch S line in the internal update with the 09:45 service-owner report of a fifteen-minute staff-write pause and two manual-queue requests. At 09:54, the planned pause has not reached its 10:00 end; do not say writes resumed. The service owner must reconcile the queue and approve the next state. The patron draft should not promise that ordinary booking writes are available. Keep M2's evidence status unchanged: a different containment branch does not make an unattributed claim true or false.

Optional correction drill: suppose a fictional earlier draft, not an issued statement, read “All bookings are restored and no customer information was affected.” Mark both clauses unsupported or contradicted, retain it in a version log as draft-v0, and produce draft-v1 linked to P1/C1, V1 and M2. If the sentence had already been sent in a real organization, an authorized communications lead would need to assess and issue a correction through the proper channel; the learner cannot decide that process from these synthetic cards.

Assessment rubric (six points): one point for a ledger that dates and classifies all five claims; one for an internal update that distinguishes Branch S's narrow action from the unresolved booking and audit checks; one for a patron draft that is useful without premature restoration or breach claims; one for routing M2 to a bounded privacy assessment without treating R24 as a permanent all-clear; one for naming approvals, audience and a 10:05 checkpoint; and one for retaining version history and correctly handling the Branch P or correction variation. A perfect classroom score demonstrates careful wording under these supplied facts. It does not establish that the communications route works in a real incident or that a legal notice is unnecessary. A model packet follows the F1 replay result in the final appendix.

Worked checkpoint

An unavailable service owner creates an approval gap. The team may preserve facts and seek the documented alternate, but neither an unanswered message nor an exercise role-play grants permission for an unapproved service change.

Practice — Lesson 17

EX043 — Preservation request

Objective: request time-sensitive evidence without a fabricated deadline. Inputs: Round B, R9, R14–R15 and Module 2's preservation fields. Output: a request naming source, booking IDs or bounded event interval, necessary fields, policy-clock question, approving role, collector, restricted storage/access and actual collection status. R15 says detailed audit records are deleted after 24 hours unless copied; ask the custodian what starts that clock rather than calculating an exact expiry from R9 alone. A score of 2 says requested until a copy and collection time are documented.

DEL4 extension: Separate a preservation request drafted, its receipt by the authorized custodian, and a collected and checked copy. State the escalation when receipt is unconfirmed; none of these stages supplies R15’s missing policy-clock anchor.

Worked answer: EX043 in the final appendix.

EX044 — Decision checkpoint

Objective: make a reversible 09:37 recommendation. Inputs: Round C, R17–R21 and the section 3.3 option matrix. Output: a decision card with current evidence and uncertainty, chosen proposal, approver and executor, intended benefit, uncovered path, service cost, preservation note, fallback, verification plan and 09:45 review. Give separate proposed, approved, executed and verified states; mark any state without a receipt pending. Include one check for the protective effect and a different check for legitimate staff service. A score of 2 treats R21 as tolerance rather than approval or execution and does not cite the Branch S/P result before Round D.

DEL4 extension: Add a separate coordination-message field for proposed, authorized-to-send, attempted, delivered and current-version role acknowledgement. A recipient’s read-back of the proposal is not action approval or evidence that a control was executed.

Worked answer: EX044 in the final appendix.

EX045 — Branch S review

Objective: bound what a successful session action actually demonstrates. Inputs: Round D Branch S only, before P1/C1 or V1; earlier R1–R24 remain available. Output: a four-row claim ledger with two supported claims and two unestablished claims, each with branch pointer and limit, plus one authorized next check with scope and owner. A score of 2 limits the “no later edit” observation to the branch query's range and does not claim eradication or correct booking state.

BH4 blind-receiver check: For each existing row, verify that a cold receiver can locate the Branch S pointer and explain its limit without asking the sender. A missing pointer is a packet defect, not proof that a booking check passed or that revocation failed. Keep this answer at the branch-only checkpoint.

Worked answer: EX045 in the final appendix.

EX046 — Branch P review

Objective: account for operational effects of the pause. Inputs: Round D Branch P only, before P1/C1 or V1; R21's tolerance. Output: a queue-and-return note with the two pending requests, who holds them, a verification that writes were blocked, an owner-approved resume condition, a signal to keep the restriction, and the next checkpoint. A score of 2 does not mark the two requests fulfilled or the cause resolved and gives an explicit reconciliation step before resumption.

DEL4 extension: In Branch P only, add a proposed instruction envelope for the front-desk receiving role: the two requests stay pending until owner-approved reconciliation. Version, authorized route and read-back are required in a future test; mark all actual dispatch and receipt fields not supplied here.

BH4 blind-receiver check: Have a receiver state what is known about the two unnamed pending requests, who may approve resumption, and what current write state remains unverified. Do not import MQ3 or the later P1/C1/V1 cards, and do not infer automatic return from the fifteen-minute plan.

Worked answer: EX046 in the final appendix.

Continue studying — lesson 17 of at least 20

← Lesson 16 · Course lesson index · Lesson 18 →

Continue to the next authored daily lesson.

Lesson 18 — Frozen evidence, communication and improvement closure

Week 4, day 3. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

4.11 Controlled injects and disciplined replay

An inject is useful when it changes what the team could reasonably decide. Merely adding alarming words does not produce better learning. In the Harbor Library curriculum, each release has a defined question: Round A tests first-response boundaries; Round B tests B19 explanation and preservation urgency; Round C tests protective action versus legitimate service; Round D tests whether reported containment and later recovery checks support service acceptance.

The facilitator should prepare an inject ledger with: inject identifier, earliest release, factual content, expected decision affected, permissible source claims, prohibited inferences and fallback instructions when the learner asks for data not supplied. If an identity session detail is absent, a facilitator must not improvise a confirmed device or attacker. The appropriate reply is that the detail is unavailable in the current exercise and could be requested from a fictional custodian under the case's approval path.

A facilitator may ask a student to state the minimum missing observation that would change the proposal. At 09:20, a complete approved task-list addendum for B19 is more discriminatory than simply repeating a general suspicion. At 09:37, confirming the exact session-to-write relationship would affect how narrowly the team can target access, while R21's tolerability statement informs the business cost of a broader pause. An inject that resolves neither question should be recognized as context rather than treated automatically as heightened confidence.

Counterfactual branches require a reset. After Branch S, ask how the decision would differ under Branch P, but label the alternative as a replay and start from the same frozen Round C card. Otherwise the student may merge the reported revocation of Branch S with the two queued requests of Branch P and invent an impossible case record. A comparison can legitimately say that Branch S places more emphasis on session scope and staff reauthentication, while Branch P places more emphasis on paused writes, queue custody and resumption criteria.

The facilitator also should not reward a student for making a production-like change when the exercise permits only tabletop role-play. Instead, score whether the student specified the approval required, the exact target and a test that would detect both intended effect and legitimate-service harm. An explicit "execution not performed" field is a valid outcome.

4.12 Audit the six artifacts as one decision chain

This exercise requires a timeline, hypothesis table, action record, recovery plan, internal status message and improvement ticket. The artifacts are not six independent writing assignments: each has an input and output relationship with the others. A late inconsistency in one may reveal an earlier missing assumption.

Artifact 1: Timeline. Include the original source event time, release round and source ID. Its primary job is to prevent the analyst from proving causation merely through ordering or justifying an earlier decision with future evidence. Include a column for whether the item was actually available at the checkpoint. The timeline must not mix application activity with an interview note as if they had identical evidentiary semantics.

Artifact 2: Hypothesis table. Keep at least two explanations live, including authorized training and account use outside the approved plan; a display/state discrepancy may coexist with either. For each, identify supporting, conflicting or insufficient evidence and an authorized discriminator. An account label and a staff recollection are not human attribution.

Artifact 3: Action record. Separate recommendation, approval, execution and verification. In Round C, R19 says a session can be revoked and R21 says a staff-write pause is tolerable. Neither row confirms execution. The action record must include the expected protection, one legitimate-service negative check, uncovered routes, decision owner, fallback and review time. If an action is never executed in the round, leave its execution fields pending.

Artifact 4: Recovery plan. A plan is not a restore receipt. Before P1/C1 and V1 are released, its expected-state and tested-result fields must be labeled pending. After those separate later cards arrive, B19 and B20 do not match the P1 target, and V1's test audit lacks the actor despite its limited positive and denied-access observations. These failures prevent unrestricted acceptance. A later approved corrective operation and new comparison would be needed; nothing in these cards establishes that such a production correction occurred.

Artifact 5: Status message. Its audience and publication state matter. The exercise EX048 requests two internal sentences at the 09:45 branch result before P1/C1 and V1 are released; those later findings cannot be included. A separate post-D communication exercise can discuss the later mismatches because its evidence boundary is different. Label the two versions accordingly, and never transform a drafted message into a sent notice.

Artifact 6: Improvement ticket. A ticket closes a reusable capability gap, not the individual case symptom alone. Correcting B19/B20 addresses selected bookings. Testing the missing V1 audit actor or an outdated restore rehearsal addresses whether the next response can be investigated or recovered safely. A ticket needs a directly accountable owner, due date, test fixture, evidence artifact, pass/fail rule and procedure for a failed retest.

The six documents must agree on unresolved conditions. A status message claiming full recovery is inconsistent with a recovery plan that records failed booking and audit gates. A summary saying a session was revoked at 09:37 is inconsistent with the frozen Round C action proposal and the later 09:45 branch report. An evaluator should treat those as material reasoning defects, not stylistic differences.

4.13 Compare the operational liabilities of both branches

Choosing Branch S or Branch P does not change the canonical pre-branch evidence. It changes what the learner must verify and hand off.

For Branch S, the reported session revocation is an observed fictional branch action, not proof of eradication. The narrow quiet query does not cover every route or time; staff reauthentication is a service effect. The next operator needs the identity-action scope and the process for restoring authorized staff access, while the service owner still needs to resolve incorrect booking state and the later V1 audit failure.

For Branch P, a fifteen-minute staff-write pause begins at the reported 09:45 branch checkpoint and creates two pending manual requests. Those requests are not accepted reservations. The service owner must assign custody, confirm each request identifier, assess conflicts with current state and authorize reconciliation before resuming writes. At 09:54 the planned fifteen-minute interval has not yet reached its 10:00 boundary; saying the pause expired and writes resumed would be unsupported. Even after 10:00, the planned end is not a verified resumption receipt.

A comparison worksheet should not ask simply "Which branch stopped the attack?" Neither branch establishes the cause, and an absence of matching audit rows could reflect limited coverage. Instead compare: protection aimed at, known service side effect, business owner, required post-action verification, unresolved routes, correction dependencies and risk of reversal.

A good reversal rule is observable. For Branch S, a verified unexplained booking change after the tested session revocation can trigger reassessment of other paths and proposed controls. For Branch P, an inability to reconcile queued requests or a failed business correctness check can block write resumption. Those are criteria for another decision, not automatic authority for a real intervention.

4.14 Control the audience and approval of each message

Different audiences legitimately require different levels of technical detail. The incident lead needs decisions and pending authorities. Front-desk supervisors need permitted operating workarounds. Patrons need an accurate, usable service instruction. The privacy contact needs sufficient provenance to assess an alleged data-access event. These are related messages but not interchangeable disclosures.

NIST SP 800-61 Rev. 3 addresses coordination and communications in cybersecurity incident response and recovery. The audience matrix below is an original classroom adaptation; it does not decide legal notification duties.

A message is itself a controlled artifact with version, audience, approval, release time and superseded-version links. A draft is not an issued notice. When a fact changes after a message was actually sent, an authorized communications role would need to preserve the original and assess a correction; silently overwriting it destroys the history of what recipients were told. The fictional case supplies no record that an erroneous public message was sent.

4.15 Verify improvement closure with a measured test

An improvement ticket is not complete when a team marks a task "done." Completion should mean that the identified capability passed a defined test and a reviewer accepted evidence of the result. Prefer one owner and one verifiable weakness per ticket rather than an unbounded "improve the SOC" assignment.

A suitable ticket has: identifier; evidence pointer; risk statement; accountable owner; deadline; planned change; prerequisites; authorized isolated test; expected positive and negative outcomes; review owner; supporting artifact; and next action on failure. The ticket can remain open despite an implementation claim if the verification result is missing.

Example — audit attribution

• Gap: V1's isolated authorized booking test has a UTC timestamp but blank actor.
• Owner: application/audit owner; incident lead reviews closure.
• Change: identify and correct the missing synthetic actor-field propagation in the tested path.
• Controlled test: execute one approved fictional staff edit and one denied unauthorized edit in an isolated environment, capturing the application version, expected actor identifier, UTC event time, request key and authoritative state.
• Pass: the authorized record contains the expected actor and time and matches the declared write, while the unauthorized attempt is denied with state unchanged; the reviewer can reproduce the selection.
• Fail: actor remains empty, denied operation changes state, or source attribution/coverage is insufficient.
• Interim measure: a named owner performs restricted comparison and escalation until a passing test and explicit closure decision are recorded.

A failure should create a new decision, not force the score to pass. Record whether the defect was caused by the test setup, source mapping or incomplete instrumentation only after evidence supports the classification. A corrective-action ticket may legitimately close with a changed design and documented residual risk, but that is a distinct owner-approved decision—not a fabricated test pass.

For a restore-readiness ticket, require an actual isolated import and owner comparison; the mere presence of a backup file does not close it. For a handoff-readiness ticket, require a blind receiver to identify current branch status, approval state, failed gates and next action without asking the original analyst. The blind handoff is a measured learning task, not proof of future production performance.

4.16 Choose metrics that cannot be gamed by easy exercises

Measure outcomes rather than counts of meetings or pages. "All personnel attended training" does not show that an analyst can distinguish an unapproved action from a proposed one. "Ten backup jobs succeeded" does not show that one approved booking dataset can be restored correctly and on time.

Useful metrics for repeated, authorized exercises include the proportion of decision cards with exact source pointers, the share of approvals with separately documented execution status, the rate of handoffs that identify open booking/audit gates, and the percentage of improvement tickets closed by independently checked evidence rather than administrative status. Those metrics require clear denominators and consistent definitions. They should not be turned into a score when the sample is too small or the evidence is incomplete.

The facilitator can also measure decision latency from card release to a justified proposal, but speed alone is not success. A student who instantly labels desk-a compromised and orders account removal is fast and wrong. Another who accurately cites the evidence, names the approver and proposes a short review may be slower and safer. Record both timeliness and completeness. A high score in a tabletop cannot stand in for a technical test of a network, identity provider or recovery process.

For an improvement rehearsal, predefine an allowed response window and what constitutes an acceptable decision. Record the actual fictional start/end and whether the learner met both the time and safety criteria. Do not infer a real organization's response-level agreement or compliance posture from this classroom score.

4.17 A valid exercise can end with open conditions

A tabletop may end while the fictional incident remains unresolved. That is a valid learning result when the packet makes open questions actionable.

In Branch S, the narrow revoked-session report does not prove which person previously edited bookings. In Branch P, the pause and manual queue do not prove that writes will be safe after resumption. After P1/C1 and V1, B19/B20 correctness and audit attribution are still failed acceptance criteria in the supplied test record. Neither branch establishes a completed production backup restore, full access coverage or a universal absence of data exposure.

The student should state what would close each open item: source, owner, authorized test, pass/fail outcome and review deadline. A final status may therefore be "tabletop concluded; response handoff and corrective actions open" instead of "incident recovered." That distinction respects both the learner's achievement and the limits of the fictional evidence.

Before handing in the final packet, run a contradiction review: Does the status message promise recovery while the data table fails? Does the action card imply approval from R21 alone? Does the final timeline use R9 at 09:05 or R17 at 09:20? Does a privacy message repeat M2 as fact? Does the improvement ticket claim a test passed when only a proposal exists? Resolve these as explicit revisions, preserving earlier snapshots. This final consistency check is often more educational than adding another paragraph of incident narrative.

4.18 Offline laboratory: F4-AUDIT release and assessment gate

Purpose: Demonstrate that a six-artifact packet can score well yet fail a critical approval gate, and that a later release cannot repair an earlier frozen decision. This classroom evaluator complements the L2 scoring case, F1 unavailable-approver rehearsal and M1/M2 message activity; it does not substitute for their evidence analysis.

Environment: Python 3 standard library, in memory. No network, files, credentials, messages or state changes. All sample scores below are invented teaching input. They are not grades given to a real learner.

Procedure: Before running, predict which references are in scope for each checkpoint; identify the prohibited future reference and mixed-branch example; then predict whether an improved 11/12 packet would pass if its approval evidence were missing. Run the code and compare the exact transcript.

LEVEL = {
    "A": 1,
    "B": 2,
    "C": 3,
    "D_BRANCH": 4,
    "D_TARGET": 5,
    "D_ACCESS": 6,
    "M_REPLAY": 7,
}

RELEASE = {
    **{f"R{i}": "A" for i in range(1, 9)},
    **{f"R{i}": "B" for i in range(9, 17)},
    **{f"R{i}": "C" for i in range(17, 25)},
    "S": "D_BRANCH",
    "P": "D_BRANCH",
    "P1": "D_TARGET",
    "C1": "D_TARGET",
    "V1": "D_ACCESS",
    "M1": "M_REPLAY",
    "M2": "M_REPLAY",
}

def validate(snapshot, refs):
    if "S" in refs and "P" in refs:
        return "BRANCH_CONFLICT"
    unknown = sorted(set(refs) - set(RELEASE))
    if unknown:
        return "UNKNOWN:" + ",".join(unknown)
    future = sorted(
        r for r in refs
        if LEVEL[RELEASE[r]] > LEVEL[snapshot]
    )
    return "FUTURE:" + ",".join(future) if future else "IN_SCOPE"

SAMPLES = [
    ("A-timeline", "A", ("R1", "R4")),
    ("B-hypotheses", "B", ("R9", "R10")),
    ("C-action", "C", ("R18", "R21")),
    ("D-status-S", "D_BRANCH", ("S",)),
    ("D-recovery", "D_ACCESS", ("P1", "C1", "V1")),
    ("D-improvement", "D_ACCESS", ("V1",)),
]

for ident, stage, refs in SAMPLES:
    print(f"{ident}: {validate(stage, refs)}")

NEGATIVES = [
    ("NEGATIVE_FUTURE_BRANCH", "C", ("R18", "S")),
    ("NEGATIVE_PREMATURE_RECOVERY", "D_BRANCH", ("S", "V1")),
    ("NEGATIVE_MIXED_BRANCHES", "D_BRANCH", ("S", "P")),
]

for ident, stage, refs in NEGATIVES:
    print(f"{ident}: {validate(stage, refs)}")

def score(values, approval_ok, scope_ok):
    total = sum(values)
    if not approval_ok or not scope_ok:
        return f"{total}/12 HARD_GATE_FAIL"
    if total >= 9:
        return f"{total}/12 CLASSROOM_THRESHOLD_MET"
    return f"{total}/12 REVISION_REQUIRED"

print("FROZEN_V1:", score((2, 1, 1, 1, 2, 1), True, True))
print("REVISED_V2:", score((2, 2, 2, 1, 2, 2), True, True))
print("NEGATIVE_NO_APPROVAL:", score((2, 2, 2, 1, 2, 2), False, True))

Check the exact output and interpretation in the final worked results.

Worked checkpoint

A corrective-action ticket with an owner and date is still open until a measured rehearsal tests the failure mode. The replay should preserve the original score and produce a separate versioned artifact for the next assessment.

Practice — Lesson 18

EX047 — Recovery acceptance

Objective: decide whether the supplied recovery evidence permits full release. Inputs: chosen branch, then the later P1/C1 and V1 cards. Output: a four-row return-to-service checklist covering booking correctness, authorized access, denied unauthorized access and actor/time audit visibility. For each, state expected result, current card result, owner and next test or correction; add a provisional service status and rollback trigger. A score of 2 marks B19/B20 mismatched and V1's blank actor as failed criteria rather than calling the book's simulated case recovered.

BH4 blind-receiver check: A new responder must locate each P1/C1 or V1 source and classify booking correctness and actor attribution as failed, the two isolated access observations as limited passes, and any untested production condition as unknown. The next correction and retest require the relevant owner approval.

Worked answer: EX047 in the final appendix.

EX049 — Improvement ticket

Objective: turn a case observation into a program improvement with proof of closure. Inputs: all four rounds, R23 or V1, and sections 4.6 and 4.15. Output: one ticket with gap and evidence pointer, accountable owner, due date, bounded change, interim control, a positive acceptance observation, a negative failure control, retained test receipt and action if the test fails. Choose either stale restore evidence or blank audit actor; do not bundle unrelated work into an untestable “improve security” task. A score of 2 explains why correcting B19/B20 alone would not close the selected program gap.

Worked answer: EX049 in the final appendix.

Continue studying — lesson 18 of at least 20

← Lesson 17 · Course lesson index · Lesson 19 →

Continue to the next authored daily lesson.

Lesson 19 — Message delivery and read-back as separate gates

Week 4, day 4. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

4.19 Verify the delivery side of incident coordination

4.19.1 An accurate message can fail operationally after approval

Previous sections teach how to write a defensible update and decide which audience should receive it. An additional operational question remains: How does the response lead know that a time-critical instruction reached the role that must act on it, with the correct version and meaning?

A message may be carefully worded, approved and stored in the case record, yet never leave the author's draft. It may be sent to an unavailable channel, delivered to the wrong distribution group, received by someone without operational responsibility, or acknowledged by a person who interpreted it differently. A successful transport attempt also does not prove that an instruction was understood or performed. These are different potential failures with different evidence requirements.

Consider a fictional staff-write pause. If a front-desk supervisor continues to accept ordinary writes because the approved temporary procedure never reached the desk, the message-handling failure can cause service confusion even when the control decision itself was justified. Conversely, an unsanctioned fallback message telling staff to resume writes can undermine a continuing pause. A response team therefore needs to evaluate message delivery as a bounded operational process, distinct from message authorship and the technical validity of the original decision.

NIST SP 800-61 Revision 3, particularly its incident-response coordination and communication discussion under RS.CO, recognizes the need to communicate appropriate information to responsible stakeholders. NIST SP 800-34 Revision 1 discusses contingency-plan activation, notification and recovery coordination. The exact delivery and read-back contract below is an original OpenCyber Academy teaching model, not a NIST-required acknowledgement protocol.

The rapid-course outcome is specific: a learner should be able to say whether a message was drafted, authorized for transmission, attempted, delivered, acknowledged for a particular version, correctly read back, or still unresolved. A claim of completed operational action needs independent execution and verification evidence; no communication receipt automatically supplies it.

4.19.2 Build a chain of receipts, not a single "sent" checkbox

Treat the communication lifecycle as several distinguishable claims:

Real communication systems use differing semantics. An email server's acceptance receipt is not always a human delivery or reading receipt. A messaging application's "delivered" indicator may represent a device, not the accountable shift supervisor. An automated read receipt can be generated by software or a preview. A short reply saying "OK" may acknowledge a conversation without identifying the particular instruction or its conditions.

The training contract should therefore define each event with a producer and limit. If the fictional coordination method can prove only dispatch to a gateway, record dispatch accepted, not recipient acknowledged. If the recipient's read-back is missing, report it as pending rather than fill in an assumption based on ordinary work habits. This is the same evidence discipline used earlier in the book, now applied to coordination rather than incident telemetry.

A response lead also should avoid treating silence as consent. A recipient who fails to answer may be busy, disconnected, off shift, unable to access the selected channel, or unsure of the request. Those possibilities do not grant the sender approval to execute a service change. The appropriate outcome is a planned escalation through previously authorized contacts and procedures, recorded as a separate event.

4.19.3 Message approval and action approval are different decisions

An especially dangerous ambiguity arises when a carefully approved message describes a proposed operational control. The message may be cleared for internal coordination while the proposed action remains unapproved.

At the canonical 09:37 Round C checkpoint, R19 says the identified current session can be revoked, and R21 says a short staff-write pause is tolerable under specified business conditions. Neither record says that an actual session was revoked or that the staff-write pause was executed. A communication such as "Please review the proposed session restriction with the identity owner" could be authorized to send without authorizing the restriction itself.

The coordination record should carry two separate fields:

• Approval to communicate: Which role approved the wording, audience, classification and channel?
• Approval to execute: Which accountable authority approved the operational action, target, duration and conditions, and where is its receipt?

One must not be inferred from the other. A communications contact may approve a patron-facing draft but have no authority to stop the booking service. A service owner may approve a pause but not authorize disclosure of account details to an external recipient. A message reporting the Branch S 09:45 revocation is also different from an independent identity-system receipt that would verify the control's current technical effect.

The useful negative test is to ask whether a recipient could mistake the communication for an execution order. If so, change its action verb and state label: "proposal awaiting identity approval" should not be written as "disable now." In an authorized real system, the change process and message-routing process must retain their own evidence and permissions. The tabletop does not create those permissions.

This separation prevents a successful read-back from being used as false evidence that an earlier control was validly approved. The recipient can correctly repeat an instruction that was never authorized. The response lead must inspect both the sender's permission and the recipient's comprehension before relying on the communication as coordination evidence.

4.19.4 Define a message envelope that identifies the exact instruction

For internal incident coordination, content alone is not enough to tell whether a receipt refers to the right instruction. Two updates might mention the same case and the same account but give different operational directions.

A message envelope is a small set of metadata accompanying the bounded instruction. It should include:

These are proposed educational fields. R1–R24 does not supply a real communication system, message IDs, authenticated delivery logs or a validated staff contact list. The absence of those fields is itself a preparation gap, not a reason to invent them in the canonical record.

The message ID and version are especially useful when two messages concern a changing situation. Suppose an initial approved hypothetical communication says "continue the manual queue while staff writes are paused." A later message may report a proposed resumption, conditional on reconciliation and a new service-owner decision. It is not sufficient for the later message to have a more recent timestamp: the receiver must be able to identify the current version and the exact action authority.

A valid envelope does not magically authenticate its producer. An attacker or mistaken operator can place plausible IDs in a forged message. In an actual organization, role identity and channel trust must be addressed through approved authentication and verification processes. Our offline lab models role/version checks using simple literal fields and explicitly does not perform cryptographic authentication.

4.19.5 Distinguish transport evidence from proof of comprehension

Imagine an approved internal instruction to the fictional front desk has been transmitted through the designated channel. The sender sees a delivery indication. The coordinator might then say, "The front desk knows what to do."

That claim is too strong without additional evidence. The delivery indicator may only show that a device or server accepted the message. It does not prove the current desk supervisor saw the content, associated it with the active shift or understood whether new bookings must remain queued.

A role acknowledgement should reference the exact case and message version, and it should come from the function responsible for the next step. A response from another staff member may be valuable context but does not automatically satisfy that requirement. The role rule needs to reflect the actual organization: if a documented alternate has been delegated the task, that delegation must be established, not guessed from the person's proximity to the incident.

A read-back asks the recipient to restate the critical operational instruction rather than merely saying "seen." For the teaching example, the distinction might be:

• Weak acknowledgement: "OK."
• Meaningful bounded read-back: "For this exercise's Branch P message, keep new booking requests in the manual queue until the service owner authorizes a verified resumption; do not treat the planned end time as automatic permission."

The read-back need not reproduce every word verbatim in a real-world design, but the acceptance criterion should identify the essential action and prohibitions. Our lab uses exact strings for determinism, not because exact string equality is a universal way to measure comprehension. A real training evaluator would review whether the recipient accurately paraphrased the essential meaning and could act under the approved process.

Even a perfect read-back does not establish that the manual queue is properly kept, that a system is paused or that booking data is correct. Those outcomes need separate operational evidence. It is possible for a person to understand an instruction yet be unable to execute it because the necessary software, authorization or resources are unavailable.

4.19.6 Use stage-aware messages in the Harbor Library tabletop

A useful communication rehearsal should check whether the message contains only facts available at the checkpoint when it is supposedly drafted or issued. An accurate later sentence may have been unavailable earlier.

At Round A, 09:05, the case has R1–R8 only. A suitable internal coordination message could request the training-owner task list and identify current uncertainty. It cannot mention B19 or a confirmed credential compromise.

At Round B, 09:20, R9–R16 may be discussed. R15 makes a bounded preservation contact urgent, but its 24-hour retention rule has no confirmed policy anchor. The message may request source availability and policy clarification; it cannot assert a specific deletion instant or that an export has been completed without a receipt.

At Round C, 09:37, R17–R24 may inform a proposed response option. R21 supports discussing a fifteen-minute staff-write pause but is not the actual pause approval. A message can request the proper decision and identify service costs; it cannot say Branch P has already occurred.

At the first Round D branch release, 09:45, select either Branch S or Branch P. Under S, an internal message may report the fictional session revocation, narrow quiet query and staff reauthentication, while retaining the limits on other access paths. Under P, it may report the fictional pause and two pending manual requests, but not the contents of those requests or proof of successful reconciliation. A message for one branch must not silently include the other's reported effects.

P1/C1 and V1 arrive later, each as its own card. Their booking mismatches and audit failure cannot be inserted into an earlier 09:45 message produced before their release. M1/M2 are optional post-D communication injects with still later release times. If the facilitator uses them, M2 is an unverified forwarded claim and must not be converted into an established exposure report.

This stage discipline is already taught in the book's F4-AUDIT exercise. The new challenge here is whether the correct stage-aware message was routed, received, acknowledged and read back in the declared scope. Passing the first part does not prove the second.

4.19.7 Channel failure is an operational condition, not permission to broaden recipients

During a disruption, the normal coordination channel might be unavailable. A recovery plan should define approved alternatives before the incident. An alternative route may be an organizational telephone tree, an approved independent messaging service or a designated communications coordinator. The right choice depends on local policy, trust, confidentiality, accessibility and records requirements.

Do not improvise a fallback by forwarding restricted incident details through a personal account or an unrelated public group. A channel that remains reachable may be unsuitable for sensitive operational information. It also may be difficult to preserve evidence of what was delivered, to whom and when. The response lead should ask whether the chosen fallback supports the necessary classification of the message and whether recipient identity can be checked.

A beginner-friendly fallback plan can have three levels:

1. Primary route: use the approved organizational channel to the accountable role, with the prescribed message ID and version.
2. Authorized alternate: after the specified failure or acknowledgement condition, try a preapproved independent route to the same responsible role or its documented alternate, preserving the minimum necessary content.
3. Escalation: if the required acknowledgement cannot be obtained, report the unresolved communication state to the incident lead for a risk decision; do not infer consent.

The fallback must not be treated as successful simply because the sender clicked a second "send" control. It needs its own attempt, delivery and acknowledgement evidence. If the alternate lacks confidentiality or proper records, the message may need to be shortened to a request for contact rather than the full operational instruction.

NIST SP 800-34 Rev. 1 addresses notification and coordination in contingency planning. NIST SP 800-84 discusses training and exercises for plan capabilities. Neither source specifies Harbor Library's channels or approves sending messages on personal accounts. The specific fallback steps above are an original small-team teaching contract.

4.19.8 Set an acknowledgement rule without inventing a service-level agreement

An instruction may be urgent because a front-desk team needs to know whether writes are currently paused. A response lead might define a target response window for that internal role. However, the canonical Harbor Library exercise supplies no operational messaging service-level agreement, no contact reliability measurement and no approved fallback roster. The learner should not invent a real organization's maximum acknowledgement latency.

For a classroom rehearsal, a deadline can be explicitly marked as hypothetical and chosen by the facilitator as part of the fixture. The response coordinator then tracks whether the expected acknowledgement arrived by that invented time. That measures student reasoning on a supplied rule; it does not create a contractual obligation or prove the same performance in production.

The needed concepts are:

• Deadline for the receipt: When should a particular role acknowledge this particular version?
• Observation cut-off: When did the coordinator check the receipt store or exercise card?
• Escalation condition: What happens if there is no valid response by the declared threshold?
• No-reply meaning: "Unconfirmed as of the check," not "the instruction was rejected" or "approval granted."
• Recovery of contact: How does a later authenticated acknowledgement change the status without erasing the earlier gap?

Do not confuse response-time measurement with event-time ordering. A valid acknowledgement must refer to the message version that was actually in effect and must be associated with the expected role. A fast acknowledgement from the wrong recipient can be less useful than a slower correct one. Conversely, a correct recipient may reply after the response lead already changed the instruction; that acknowledgement is evidence concerning the old version, not proof that the newer instruction was understood.

An escalation route should identify who owns the risk decision when the communication remains uncertain. It should not give the coordinator unrestricted authority to interrupt a service or publicize technical details.

4.19.9 Version changes and delayed acknowledgements create a different hazard

A communication update may be issued because the team's recommendation or service state changed. A recipient might have acknowledged version 1, while version 2 is now the operative message. If the incident record stores only "acknowledged = yes," the coordinator may mistakenly conclude that the current instruction was accepted.

Define the receipt key as the message ID, version and intended role. An acknowledgement lacking one of those fields may remain usable as context but should not satisfy the current-message read-back gate without further verification.

For an explicit classroom variant, suppose a hypothetical Branch P message initially describes the paused-write workflow. A later version corrects the wording of the return condition. An acknowledgement for the earlier version proves, at most, that the older text reached someone under the stated role checks. It does not demonstrate that the recipient knows the newer condition.

A version change should therefore include a supersedes pointer and an explanation of what changed. If recipients may have acted on the earlier message, the coordinator should identify whether a new correction or callback is needed. Silently editing an already-dispatched draft creates a false history of what was transmitted.

Multiple messages can also cross in transit. The more recent one may arrive first, while an old retry arrives later. A robust operational plan should tell recipients how to verify which instruction is current before taking an irreversible action. The rapid course does not implement such a distributed communications system; it trains the reasoning necessary to recognize its failure modes.

This is separate from L2's revision scoring. L2 asks whether a learner's artifact was complete at its frozen checkpoint. The issue here is whether a recipient has acknowledged the current authorized operational meaning of a specific message version.

4.19.10 Retries are not evidence of more independent instructions

When delivery is uncertain, a coordinator may need to retry through an approved route. That introduces two counting problems. First, multiple attempts may refer to the same logical message. Second, the recipient may encounter duplicate copies after having already acknowledged one.

A delivery ledger should preserve all attempts for auditability but group them under the same message ID and version for the purpose of deciding whether the operational instruction is current. Sending the same version twice does not create two independent approvals or two separate write-pause decisions. If two attempts use different channels, each attempt retains its own routing evidence and trust limitation.

The difference is similar to the manual-queue reconciliation problem in Module 3, but it concerns communications, not business booking writes. The fact that one logical message has two attempts does not guarantee exactly-once reading or exactly-once operational execution. A later recipient who sees the retry might mistakenly perform the instruction twice unless the instruction and action workflow have appropriate safeguards.

An acknowledgement should therefore avoid ambiguous references such as "I handled your second message." It should identify the specific message ID/version and what action, if any, is proposed or already completed. The coordinator records whether the recipient's read-back was checked and whether an execution receipt is still pending elsewhere.

Retry success should also be measured honestly. If a primary attempt was never confirmed and a fallback produced a valid read-back, the ledger should retain the primary gap and the fallback success. Rewriting the whole incident communication as "delivered on first attempt" would hide the very weakness the after-action review should address.

4.19.11 Role identity and device delivery are not equivalent

Many organizations have roles shared across shifts. The "front desk" is an operational function, not necessarily one named person's permanent device. A response instruction might arrive on the shift mailbox when the responsible supervisor has just left. A success indicator for that mailbox says little about whether the current accountable role is prepared to act.

A useful route contract distinguishes three addresses:

• The logical recipient role responsible for the outcome.
• The technical endpoint or contact route used for transport.
• The authenticated human or documented alternate who can provide the required acknowledgement under the organization's rules.

This separation matters in a shift transition. If an old shift member replies that they read version 1, the incoming shift still may need a new handoff and valid read-back for version 2. The response lead should not infer that role continuity follows from mailbox continuity.

An alternate may be valid when appointed under an approved procedure, but not merely because another person responded first. The workbook should allow the coordinator to mark a reply from an unrelated role as not satisfying the required acknowledgement while still retaining it as a received message.

This is distinct from F1. F1 asks what to do when the service owner who approves a write pause is unavailable. Here the service owner may be available and the instruction may be valid, yet the operational receiving role may not have acknowledged the current direction. A failure at the reception boundary does not change who can authorize the underlying control.

An authorized functional exercise could test this with role rotation and a bounded delivery simulation. This chapter's offline lab uses literal role names without contacting any real device or authenticating a real person.

4.19.12 Operational handoff requires a confirmed next holder of the task

A response team may transfer an open task between shifts. A handoff note can be complete on paper yet fail operationally if nobody assumes responsibility for the next check. The sending responder should identify the exact recipient role, the current decision, the open obligations, the next checkpoint and the source pointers needed to proceed.

Use an ownership read-back for critical tasks:

"I am receiving responsibility for the bounded Branch P queue review, not permission to resume writes. The two pending requests remain unverified; the service owner must decide on resumption and booking reconciliation."

This is an invented example of a good read-back after a Branch P release. It does not mean that the canonical two queue requests have been inspected or resolved. It confirms only that the recipient understands the pending obligation within the simulated exchange.

A bad handoff would say:

"Writes were paused, the window probably ended, so the next shift can turn everything back on."

It invents authority from elapsed planned time and omits the service and data acceptance requirements. Even if the statement was successfully delivered, the content is unsafe. Communication delivery quality and instruction correctness are two gates, not one.

The handoff packet should also identify which planned work has not been approved. A transfer of responsibility does not promote an unapproved proposal to an executed action. The next responder can prepare the required request, confirm the status through the relevant owner and record a new result. The original sender's unfinished work must remain traceable.

A recipient challenge is appropriate: ask the new role holder to state one reason why the service must remain restricted or why a particular verification is still pending. A correct answer demonstrates useful comprehension in the classroom. It does not prove actual technical recovery.

4.19.13 Audience restrictions apply to the fallback path too

An internal operational instruction may contain details that should not appear in a patron-facing status. Sending it through a fallback channel does not change the audience classification. A communication failure is not permission to forward account names, booking identifiers or unverified exposure rumors broadly.

For the canonical case, technical owners may need to know that a specific session action was reported in Branch S. Front-desk supervisors may need instructions about permitted booking intake. Patrons may need a practical, owner-confirmed help route without the account name. The privacy contact may need to evaluate M2's unverified forwarded claim after its optional release. The message-delivery ledger should reflect those distinct audiences, and the fallback route must not silently expand them.

If a public status draft is approved but an approved publication channel is unavailable, the fact that the team can reach a private messaging group does not automatically make that group an acceptable substitute. The responsible communications and service owners must decide the audience and means under the organization's process. The tabletop supplies no jurisdiction or legal notification threshold and cannot decide whether a statutory notice is owed.

A safe fallback might send a minimal contact request through an approved alternate and leave sensitive details in an authorized channel. That can be operationally less informative than the original message, but it reduces the risk of disclosure through an unverified route. Record the difference: "contact requested" is not "incident details delivered," and neither is "recipient understood the operating instruction."

The extra verification requirement is not bureaucratic decoration. During a stressful incident, recipients may act on whichever message they see first. Separating role, version, authorization and channel trust prevents a perfectly formatted but misrouted instruction from becoming an avoidable additional service failure.

4.19.14 Contrastive worked example: delivered does not mean safely coordinated

Incorrect fictitious conclusion after a Branch P release:

"The front-desk update was approved and the sending tool marked it delivered, so everyone knows the pause is active and can safely resume writes at 10:00. The message has an acknowledgement, therefore the two queued reservations must have been completed."

This makes several unsupported leaps. A delivered indicator does not identify the current operational role or prove comprehension. The acknowledgement may refer to an earlier version or an unrelated role. The planned end of the fictional fifteen-minute interval does not establish a completed resumption decision. The Branch P card reports two pending requests, not completed bookings. Nothing about a communication receipt supplies the business-state or queue-reconciliation evidence needed to accept full service.

Correct bounded classroom assessment:

"Only after the separate Branch P card is released may the coordination note report a 09:45 fictional staff-write pause and two pending manual requests. The recipient must be reached through an approved role/channel, acknowledge the current instruction version and correctly state that requests remain queued until the service owner decides on reconciliation and resumption. If transport, role acknowledgement or read-back is missing, the coordination state remains unconfirmed and must be escalated under the prescribed exercise rule. Even a successful read-back does not prove write-path effectiveness, booking correctness or permission to resume."

This preserves three boundaries at once: what evidence was released, what communication result was checked, and what operational action still needs separate approval and verification.

In a technical incident review, a precise statement such as "the current front-desk instruction version has a valid read-back in the approved classroom route" is more defensible than "all staff were informed." The former identifies exactly what was demonstrated; the latter suggests a coverage the fixture does not measure.

4.19.15 An after-action review should locate the failed communication link

If the coordination process fails, the improvement plan should address the specific link that failed. "Communicate faster next time" is too general to test. Possible defects include an outdated contact route, missing alternate, unclear message version, absent role acknowledgement, an insecure fallback, or an instruction whose critical condition was not reflected in the read-back.

Each defect needs its own evidence:

The exercise should make a distinction between a working process and a plausible description of that process. A roster written into a playbook is not a tested emergency contact path. A read-back field in a template is not a received read-back. An after-action ticket closes only when the declared functional or tabletop test has been completed and a reviewer can inspect the result.

NIST SP 800-84 offers general exercise and evaluation guidance. Its functional-exercise examples illustrate that participants can rehearse notification procedures; our precise receipt statuses and negative controls are original teaching constructs, not a direct copy or NIST pass standard.

4.19.16 Measure recipient coverage without fabricating a success rate

A team may report "100% communicated" after receiving one acknowledgement. That statement is meaningless without a declared set of required recipient roles and a rule for which receipts count.

For an exercise, define the required recipient set before sending. A narrow Branch P internal instruction might require the front-desk supervisor and service owner under a chosen fictional procedure. A privacy allegation may require the privacy contact instead, only after the M replay releases the claim. Do not count irrelevant or future roles simply to enlarge the denominator.

For each required role, track the current message version, permitted channel, dispatch attempt, delivery status, role acknowledgement and read-back result. If the same person acknowledges twice, do not treat that as two distinct roles covered. If the message changes, the earlier version's acknowledgement does not count for the new version. If an attempt is unconfirmed, it remains in the record as a gap.

A bounded measure might be expressed as: "Of the two roles required by the declared classroom routing rule, one provided a current-version read-back and one remained unconfirmed at the check." This still does not measure the entire organization, every shift or actual behavior. If the required recipient set was never approved, the success ratio is not well defined; the proper improvement is to establish the routing contract, not to guess a percentage.

Time can also be measured, but it must be interpreted carefully. A short delay to the wrong audience is not successful coordination. An acknowledged instruction with incorrect operational meaning is not a pass. A communication exercise should therefore score both the timeliness of an attempt and the validity of the receipt. These may lead to different recommendations.

Never report transport-delivered percentage as operator-comprehension percentage unless the evidence contract actually connects those measurements.

4.19.17 From tabletop reasoning to an authorized functional rehearsal

This rapid course exercises reasoning with synthetic records. It cannot validate the reliability of a real email service, telephone tree, emergency contact list or authentication control. A later authorized functional test would require additional procedures and safeguards.

A responsible test plan would define the exact message category, approved recipients and alternate contacts, expected channels, start and end conditions, permitted test data, minimum retained receipt metadata, participant consent or notice under the organization's policy, and an immediate stop rule if a real operational effect would occur. A message should be unmistakably marked as an exercise to prevent participants from treating it as a live incident instruction.

An observer would record what the sender did, what the transport system actually reported, which role replied, which version was acknowledged, what the recipient understood and whether any intended separate operational task was completed. If there was an outage, the observer should preserve the failure and escalation rather than retroactively claim the fallback succeeded. A reviewer should check whether the procedure could be performed when the usual approver or channel was unavailable, but without granting new authority that the exercise never specified.

A passing functional notification test would support only the tested participants, routes, channels and time window. It would not prove that a production incident will unfold identically, that the recipients are always reachable or that the service can be restored. The difference between a training outcome and an operational guarantee must remain explicit.

This is a useful bridge from an introductory tabletop to later technical education: describe the required signal and proof, test it in isolation, identify the condition that would invalidate the conclusion, and preserve the limits.

4.19.18 Section synthesis: coordination is verified at the receiving boundary

Incident coordination is not complete merely because a good message was drafted or approved. The response team needs a bounded record showing that the right role received the current version through an approved route, that a valid acknowledgement and read-back were obtained when required, and that unanswered contacts were escalated without inventing permission.

None of those receipts proves an account was disabled, a write pause held, a backup restored or the booking schedule corrected. Those remain separate technical and business acceptance questions handled elsewhere in the book. The added skill is to make communication failure visible before it silently becomes operational failure.

The Harbor Library release rules remain unchanged: Round A R1–R8, Round B R9–R16, Round C R17–R24, then one reported Branch S/P result in Round D, followed by P1/C1 and V1 only at their later releases; F1 and M1/M2 are independent optional variants. The communication lab below demonstrates its own invented receipt outcomes without inserting them into that history.

4.20 DEL4 offline laboratory — read-back and message-delivery gate

Laboratory status: Entirely synthetic, in-memory exercise. DEL4 does not send any messages, authenticate recipients or interact with a booking system. The fixture selects a hypothetical Branch P communication context after a Branch P release; it does not assert the canonical branch occurred outside that exercise.

Goal: Distinguish dispatch authorization, approved channel, attempt, transport delivery, acknowledgement role, message version and read-back. Reject later-card content at an earlier checkpoint and a message belonging to the other branch. Treat missing and overdue acknowledgements as unresolved or escalated, not tacit consent.

Environment: Python 3 standard library, no files, network, email, SMS, telephone calls, credentials or side effects.

Fixture fields: The strings are simulated assertions; authorized=True represents only fictitious permission to dispatch a message, not approval to execute a service change. delivered=True is a synthetic transport field, not proof of human reception. Exact text equality implements this laboratory's narrow read-back check, not a universal natural-language comprehension test. overdue is a facilitator-supplied Boolean, not a measured contractual deadline.

Reproducible Python 3 program

RELEASE = {
    "C": 3,
    "D_BRANCH": 4,
    "D_ACCESS": 6,
    "M_REPLAY": 7,
}

def packet(
    name, release="D_BRANCH", branch="P", role="FrontDesk",
    version=2, authorized=True, channel_ok=True, attempted=True,
    delivered=True, ack_role="FrontDesk", ack_version=2,
    readback="Keep requests pending",
    expected="Keep requests pending", overdue=False
):
    return dict(
        name=name, release=release, branch=branch, role=role,
        version=version, authorized=authorized, channel_ok=channel_ok,
        attempted=attempted, delivered=delivered, ack_role=ack_role,
        ack_version=ack_version, readback=readback, expected=expected,
        overdue=overdue,
    )

FIXTURES = [
    packet(
        "C-COORD", release="C", branch="ANY", role="IncidentLead",
        version=1, ack_role="IncidentLead", ack_version=1,
        expected="Review proposal only", readback="Review proposal only"
    ),
    packet("P-NO-AUTH", authorized=False),
    packet("P-NO-SEND", attempted=False),
    packet("P-WRONG-CHANNEL", channel_ok=False),
    packet("P-NO-DELIVERY", delivered=False, overdue=True),
    packet("P-ACK-PENDING", ack_role=None, ack_version=None, readback=None),
    packet(
        "P-ACK-OVERDUE", ack_role=None, ack_version=None,
        readback=None, overdue=True
    ),
    packet("P-WRONG-ROLE", ack_role="Analyst"),
    packet("P-STALE-VERSION", ack_version=1),
    packet("P-WRONG-READBACK", readback="Resume writes now"),
    packet("P-VERIFIED-READBACK"),
    packet("S-BRANCH", branch="S"),
    packet("D-RECOVERY", release="D_ACCESS"),
    packet("M2-PRIVACY", release="M_REPLAY"),
]

def evaluate(p, checkpoint="D_BRANCH", selected_branch="P"):
    if RELEASE[p["release"]] > RELEASE[checkpoint]:
        return "FUTURE_RELEASE"
    if p["branch"] not in ("ANY", selected_branch):
        return "WRONG_BRANCH"
    if not p["authorized"]:
        return "HOLD_NOT_AUTHORIZED"
    if not p["channel_ok"]:
        return "HOLD_CHANNEL_NOT_APPROVED"
    if not p["attempted"]:
        return "READY_NOT_SENT"
    if not p["delivered"]:
        return "ESCALATE_DELIVERY" if p["overdue"] else "DELIVERY_UNCONFIRMED"
    if p["ack_role"] is None:
        return "ESCALATE_ACK" if p["overdue"] else "ACK_PENDING"
    if p["ack_role"] != p["role"]:
        return "ACK_WRONG_ROLE"
    if p["ack_version"] != p["version"]:
        return "ACK_STALE_VERSION"
    if p["readback"] != p["expected"]:
        return "READBACK_MISMATCH"
    return "READBACK_CONFIRMED_IN_FIXTURE"

for item in FIXTURES:
    print(f"{item['name']}: {evaluate(item)}")

# Two attempts at the same logical message version.
ATTEMPTS = [
    ("P-VERIFIED-READBACK", 2, "primary"),
    ("P-VERIFIED-READBACK", 2, "retry"),
]
print(
    "RETRY_CHECK attempts=", len(ATTEMPTS),
    " logical_versions=", len({(n, v) for n, v, _ in ATTEMPTS}),
    sep=""
)

assert evaluate(FIXTURES[10]) == "READBACK_CONFIRMED_IN_FIXTURE"
assert evaluate(FIXTURES[12]) == "FUTURE_RELEASE"

Exact expected output — executed in Python 3

C-COORD: READBACK_CONFIRMED_IN_FIXTURE
P-NO-AUTH: HOLD_NOT_AUTHORIZED
P-NO-SEND: READY_NOT_SENT
P-WRONG-CHANNEL: HOLD_CHANNEL_NOT_APPROVED
P-NO-DELIVERY: ESCALATE_DELIVERY
P-ACK-PENDING: ACK_PENDING
P-ACK-OVERDUE: ESCALATE_ACK
P-WRONG-ROLE: ACK_WRONG_ROLE
P-STALE-VERSION: ACK_STALE_VERSION
P-WRONG-READBACK: READBACK_MISMATCH
P-VERIFIED-READBACK: READBACK_CONFIRMED_IN_FIXTURE
S-BRANCH: WRONG_BRANCH
D-RECOVERY: FUTURE_RELEASE
M2-PRIVACY: FUTURE_RELEASE
RETRY_CHECK attempts=2 logical_versions=1

Worked interpretation

C-COORD simulates a correctly read-back Round C coordination message saying only "Review proposal only." It does not approve or execute the session restriction or write pause.

P-NO-AUTH blocks dispatch because the invented permission flag is false. This is a send-authorization failure, not evidence that the operational control was accepted or rejected.

P-NO-SEND shows that an authorized message can remain untransmitted. P-WRONG-CHANNEL detects an explicitly unapproved route rather than improvising delivery. P-NO-DELIVERY demonstrates the overdue delivery-escalation condition; the program has no evidence the recipient actually received anything.

P-ACK-PENDING and P-ACK-OVERDUE distinguish a missing acknowledgement still within the hypothetical window from an overdue missing acknowledgement. Neither status grants consent. P-WRONG-ROLE rejects a response from a function other than the intended receiving role. P-STALE-VERSION rejects an acknowledgement of version 1 for version 2. P-WRONG-READBACK identifies a contradiction between "Keep requests pending" and "Resume writes now"; the presence of a reply does not make the instruction safe.

P-VERIFIED-READBACK is the most favorable limited classroom outcome. It means that the fixture's declared role, version and expected string match after its assumed transport flags. It still does not prove the authenticity of an individual, the real effectiveness of a write pause, reconciliation of the two canonical Branch P requests, or approved resumption.

S-BRANCH prevents mixing Branch S into a selected Branch P packet. D-RECOVERY refuses a later V1/P1/C1-stage message at the first branch release; M2-PRIVACY refuses optional M2 material until its distinct later replay. The source-release checks protect the teaching scenario, not a real information system.

RETRY_CHECK prints two attempt records for one logical message ID/version pair. The attempts should remain separately auditable, but they do not create two independent instructions or acknowledgements.

Negative tests, safeguards and limits

Before running, predict which of the statuses would require immediate fictional escalation and which would require correcting the audience, message version or wording. The learner may change only a copy of one fixture row at a time, label the variant and rerun. For example, replacing P-STALE-VERSION's acknowledgement version with 2 should allow the later read-back check to pass under its other assumptions. Replacing P-VERIFIED-READBACK's message branch with S must make the same row fail in the selected Branch P context.

The code is not a communications platform. It cannot verify whether a message was cryptographically authenticated, whether a human read a device notification, whether an alternate channel was suitable under a real organization's privacy policy, or whether a required action was carried out. It does not connect to anything and does not send messages.

Learner submission: Reproduce all fifteen output lines, identify the seven distinct barriers from dispatch authorization through read-back, write a one-paragraph Branch P communication limitation statement and identify one additional source that would be needed to prove an actual approved operational outcome. A successful submission must not call the synthetic flags real delivery receipts.

Supplementary laboratory rubric (five points): one point for exact output; one for the approval/send distinction; one for correct role/version/read-back interpretation; one for the stage and branch exclusions; and one for evidence, security and operational-limit reasoning. The laboratory does not create a new EX039–EX050 identifier or change the canonical exercise count.

Worked checkpoint

A status message can be accurate and approved yet fail to reach the intended operator. Record the approved content, route, receipt, acknowledgement and read-back independently; a transport success is not proof of comprehension.

Practice — Lesson 19

EX048 — Internal update

Objective: report the action while preserving uncertainty. Inputs: chosen Round D branch at 09:45 UTC, before P1/C1 and V1 are released. Output: exactly two sentences for an internal service-owner audience, naming the service, a supported observation and reported branch action, current uncertainty, owner and next checkpoint. For Branch P mention the manual queue; for Branch S mention reauthentication. A score of 2 does not assert breach, attacker identity, complete recovery, a validated restore or results from later cards.

DEL4 extension: Keep the status draft at exactly two sentences. Add a separate metadata line for intended recipient role, proposed message version, approved-route requirement and acknowledgement status; this is not a third sentence of the message.

Worked answer: EX048 in the final appendix.

Continue studying — lesson 19 of at least 20

← Lesson 18 · Course lesson index · Lesson 20 →

Continue to the next authored daily lesson.

Lesson 20 — Blind handoff and independent reconstruction

Week 4, day 5. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

4.21 Blind handoff and independent state reconstruction

4.21.1 The missing question in a conventional handoff

An analyst can write an accurate history yet leave the next responder unable to act safely. The writer remembers the discussion, knows which colleague supplied context and remembers why certain options were rejected. A new on-call responder may possess only the saved case packet. If that document says "account handled, recovery pending," the receiver must guess which account action occurred, whether it was proposed or executed, what was tested, and who owns the remaining work.

Chapter 04 already tells students to preserve a source ledger, freeze decisions before revealing new cards, give a reproducible handoff and score six artifacts. Section 4.15 briefly proposes a blind receiver test. The missing lesson is how to prove that a receiver can actually reconstruct the decision state rather than simply reading a polished summary.

The target is a repeatable two-role exercise: a sender freezes an evidence-linked packet; an independent receiver reviews it without speaking to the sender, locates the referenced evidence, reconstructs the relevant states and chooses a safe next request. A third evaluator can compare that answer with the supplied records, or the two participants can perform the comparison after the first answer is frozen.

NIST SP 800-84 gives official guidance for designing, conducting and evaluating IT training and exercises. The FEMA HSEEP guidance addresses evaluation of observable exercise capabilities and improvement planning. The specific blind reconstruction contract is original OpenCyber Academy teaching material, not a scoring scheme mandated by either source.

4.21.2 Define what blind means before starting

Blind does not mean withholding valid evidence. The receiver may open the permitted canonical R-series table, the chosen branch card and the later P1/C1/V1 material if those cards have been released for the selected checkpoint. Blind means no explanation from the person who wrote the packet while the first reconstruction is being prepared.

A complete contract therefore states the checkpoint, allowed sources, packet version, required receiver answers, forbidden assistance, submission deadline if one is used, evidence-preservation rule and pass/fail criteria. These elements must be established before the sender knows how the receiver will respond. Otherwise a facilitator can unintentionally move the success criteria after observing a confusing packet.

A cold receiver should not be allowed to rely on an off-record comment, a remembered classroom conversation or later facts that were not included in the declared release. Conversely, if the packet explicitly locates an allowed source, a receiver who follows that link is doing exactly what the test is intended to measure.

The facilitator may permit two distinct phases. First, an unaided reconstruction, whose answer is frozen. Second, a clarification and improvement phase, where sender and receiver discuss failures and issue a corrected version. Results from the second phase cannot be presented as though the first packet passed unassisted.

A passing blind handoff demonstrates a narrow educational capability: two people can transfer a bounded fictional incident decision using written sources. It does not prove live-system containment, real communication delivery, tested backups or operational staffing readiness.

4.21.3 Separate three documents with three different owners

The exercise uses a sender packet, a receiver reconstruction and an evaluation record. Combining them makes it harder to determine whether the receiver derived the answer or was simply given it.

The sender packet contains the case ID, checkpoint, chosen branch, versioned prior decisions, canonical source references, reported actions, unresolved business conditions, next accountable roles and review triggers. It can point to the book's existing six outputs; it is not a new seventh output in the chapter's scoring rubric.

The receiver independently writes what the packet establishes, which sources support those findings, what remains uncertain and which request should be made next. It should not claim to have performed a technical verification merely because it located an existing classroom record.

The evaluator records whether the receiver's statements follow the supplied evidence, whether critical sources could be located, which stage boundaries were crossed, whether the suggested act requires approval and what changed in any later revision. An evaluator should give a reason for each failure rather than an unexplained mark of "incorrect."

A missing pointer is primarily a packet problem if the source cannot be located under the declared conditions. A correct pointer ignored by the receiver may indicate a comprehension or navigation problem. A source that has not yet been released is neither of those; it is outside the exercise's permitted evidence.

Each outcome requires a different improvement. A sender cannot fix a missing document by saying "I explained it during the meeting," because that explanation is exactly the dependency a blind test is intended to reveal.

4.21.4 Reconstruct the knowledge boundary before the incident story

One of the receiver's first tasks is to identify what could be known at the relevant decision time. This is not the same as arranging every event in chronological order.

R9 describes a B19 edit at 09:03, but the student receives R9 only in Round B at 09:20. It cannot justify the initial 09:05 decision. R17 and R18 become available in Round C and cannot retroactively justify the 09:20 triage. R21 is available by the 09:37 checkpoint, but it merely says a brief staff-write pause is tolerable; it does not report an approved or executed pause.

The Branch S or P report appears only in Round D at 09:45. P1/C1 and then V1 become usable only in their separate later release steps. A packet drafted at the first Branch D checkpoint cannot discuss V1's failed actor field as though that fact was then known. A later complete handoff can discuss the failure, but it must not rewrite the earlier snapshot.

A useful sender packet therefore has event-time and available-at columns. A receiver should reconstruct a decision using only evidence available at that frozen point, while keeping later revisions as separately versioned records.

A packet that backdates a later source can reach a plausible final conclusion for the wrong reason. The blind test must reject that causal and temporal shortcut, even when the student happened to know the later result from reading the book.

4.21.5 Locate the evidence; do not merely repeat a conclusion

"See attached logs" is not a sufficient source pointer. The receiver must know which R-series item, branch report or exercise card substantiates each material statement. In a classroom manuscript, the record ID and correct chapter link can serve as a test locator. In a real authorized investigation, the source might require a restricted evidence store, collection receipt and access permissions.

Consider the statement "staff writes were paused." The receiving responder should ask whether this refers to R21's tolerance statement at 09:29, a proposal made by the lead at 09:37, or a fictional Branch P report of a pause at 09:45. Those are different sources and do not support the same claim.

Similarly, R23's backup-job result does not substantiate a successful restore. P1/C1 supports a limited booking-state comparison after its later release; V1 supports two limited access-test observations and a failed audit attribution check. A reviewer needs those separate pointers to diagnose why unrestricted return has not been shown.

An important source rule is locatable does not mean sufficient. A functioning link to R21 cannot transform tolerability into authorization. A valid link to V1 cannot prove booking correctness because V1's function is different. The receiver should identify both the supporting source and what it does not establish.

If a required source pointer is absent, record "not located from this packet" and request correction. Do not treat missing information as evidence that the tested outcome was negative or safe.

4.21.6 Reconstruct recommendation, approval, execution and verification separately

The sender may compress an intervention into a phrase such as "session contained." A blind receiver must unpack it into states with source support.

At Round C, the analyst can propose a bounded current-session restriction and request appropriate approval. R19 says that the current session can be revoked; this is a capability statement, not an execution receipt. The 09:37 action remains a proposal under the fixed checkpoint.

Under the separately released Branch S report at 09:45, the specified current session was reported revoked under fictional approval. That historical report does not establish that every session was removed, that a malicious actor was identified or that the action remains independently verified indefinitely.

Under the alternative Branch P report, staff writes were reported paused for fifteen minutes at 09:45 and two manual requests were pending. The planned end of that interval does not prove automatic resumption. The receiver must not claim that the two pending requests are accepted bookings.

A precise handoff distinguishes proposed at checkpoint C, approved or reported executed by a later branch, and technical effect independently verified within a known scope. It may need to say that the current technical state is unknown beyond the last supplied report.

This is why merely finding an approval signature or reading a message is not enough. A separate operational result must support an execution or effectiveness claim. The blind test evaluates whether the responder knows when to stop short of that claim.

4.21.7 A last reported state is not a verified current state

A new on-call responder often asks, "What is the system doing right now?" The packet may not contain a fresh observation at the moment of handoff. The correct answer then distinguishes a last reported condition from a current independently observed condition.

For Branch S, the last supplied branch action is a 09:45 report of revocation, accompanied by a narrow quiet booking query and staff reauthentication requirement. That does not verify all other paths, or a later independent identity check. A responder should not tell the owner that every write route is secure merely because no later edit appeared in one bounded query.

For Branch P, the last reported pause began at 09:45. A receiver at a later, unspecified time cannot infer whether writes resumed from arithmetic alone. The two pending requests also have no supplied approval or completed disposition. Their status must remain pending until a separate owner-approved reconciliation is evidenced.

An accurate current-state entry might read: "last branch-reported control noted; current effective status not independently verified in the available packet." This is an actionable limit, because it tells the next responder what needs checking.

An incorrect entry such as "pause automatically ended at 10:00" invents a transition. The responder could then issue a dangerous service instruction based on an event that has never been documented.

The baseline BH4 script below deliberately requires the separate state "not independently verified" even when a historical branch report is available.

4.21.8 Reconstruct the failed gates without replacing them with hope

After P1/C1 and V1 are released, the next responder should understand why full service acceptance is not supported. P1/C1 shows B17 and B18 matching their approved target but B19 and B20 different. The four-booking correctness gate therefore has failed items requiring owner-reviewed correction.

V1's isolated test reports that one permitted synthetic action worked and one prohibited synthetic action was denied. These are limited passes for their tested operations, not universal access guarantees. V1 also shows a blank actor field in the audit of the permitted action. That is a failed attribution criterion, not merely an unknown that can be considered a pass.

A cold receiver must reconstruct this mixed evidence, not compress it to "restore passed" or "everything failed." The correct handoff identifies the successful limited observations and the failed mandatory criteria separately.

Neither the P1/C1 comparison nor V1 says that the actual production system has been corrected or that a later independent comparison passed. R23's earlier backup-status report cannot supply the missing restore evidence. The later RTE3 synthetic recovery-time fixture is also a distinct lab, not a historical Harbor Library result.

A good receiver can turn these failures into a narrow request for the service owner and audit owner. A bad receiver might choose the newest backup or close the case despite the unresolved mismatches; that is precisely the next-action failure this exercise must detect.

4.21.9 The next safe act is a request, not an unapproved repair

Reconstructing the past is only useful if it supports a responsible next decision. Ask the receiver to state one next action, the person authorized to approve it, the evidence the action requires and the review trigger.

In the later Branch S scenario, a defensible choice is to request a service-owner-approved B19/B20 correction plan and a new bounded booking-state comparison, while also assigning the audit owner to investigate and retest the blank actor field. The request can be prepared by the incident team, but no source grants automatic permission to overwrite production bookings.

For Branch P, the next request must additionally account for the two unnamed manual-queue items. A new responder may request a restricted manifest, approval status and reconciliation plan; they may not mark the two entries fulfilled based on the separate MQ3 lab or on a guessed queue content.

Unsafe next steps include immediately resuming writes, claiming full recovery after a limited login test or treating the 09:45 reported control as an unrestricted continuing guarantee. A receiver who makes such a recommendation fails the safety purpose even if they located every source.

The next review should include an observable event or deadline: a verified new unexplained edit, a failed correction comparison, an unsuccessful audit retest or a required owner response not received. The trigger is a future condition, not a newly supplied R-series fact.

The receiver's next-action card should therefore distinguish may request now from may execute only after specified authorization.

4.21.10 A sealed packet must identify its exact inputs

The sender should freeze an inventory with version and contents before handing it over. The manifest need not reproduce every record, but it must identify the allowed source and the exact records or sections that support important claims.

A late Round D packet for Branch S might cite R17/R18 in Module 3, Branch S in Module 4, and the separately released P1/C1 and V1 in Module 3. The receiving responder can then follow those pointers to verify the narrow statement about training authorization, later booking changes, branch action, incorrect selected booking values and failed audit actor.

If C1 is missing from the manifest, an assertion that B19/B20 fail the approved target is not independently reconstructible from the packet alone. The correct test result is missing pointer, not proof of correct bookings.

The sender also should list important omissions: no authenticated real operator identified, no production correction result, no full service acceptance, no verified current control status beyond the reported branch scope. Those declarations are useful because they prevent the receiver from filling blanks with customary assumptions.

A source locator is not permission to bypass actual access rules. In real response work, evidence access must be appropriately authorized. The fictional book uses public synthetic sources, but the concept of permitted scope still matters to how the packet is evaluated.

An effective packet can be short if its pointers and decisions are precise. Adding pages of narrative cannot replace an absent source or owner.

4.21.11 Two roles, two independent records

The sender writes the packet, then stops contributing information. The receiver reviews the packet and permitted citations without verbal or written assistance from the sender. The evaluator compares the receiver's first frozen answer with the canonical cards.

This procedure exposes a difference that ordinary peer review may hide: the sender may be able to explain the packet, yet the packet itself may not contain the explanation. If the sender supplies an important source only after a question from the receiver, that later disclosure may improve the packet but cannot make the first attempt pass unaided.

The receiver should have a fixed set of questions:

1. What phase and branch are in scope?
2. What facts were available to the earlier 09:37 decision?
3. What was only proposed then, and what did the later branch report?
4. Where can each material source be located?
5. Which business and audit checks passed narrowly, failed or remain unknown?
6. What safe request comes next, who owns it and what triggers reassessment?

The sender should not be permitted to correct a receiver's answer until the receiver has submitted it. The receiver should not search unreleased variants or ask the facilitator to supply a missing "answer" that the packet was meant to include.

A first attempt should remain frozen and attributable to the learner's work, even if later revisions demonstrate substantial improvement.

4.21.12 A third-party observation must distinguish packet defects from learner defects

An evaluator should not reduce all reconstruction failures to "poor communication." The root of a failed handoff may lie in the sender's evidence pointers, in the receiver's interpretation, or in an explicitly unavailable source.

If C1 is absent from an otherwise complete packet, the sender has not provided the location necessary to assess the booking-state comparison. If C1 is correctly located and the receiver ignores it, the receiver's retrieval or reasoning needs improvement. If C1 has not yet been released, the test must not demand that the receiver use it.

These distinctions inform corrective work. A missing source pointer may be fixed by updating the packet manifest. A misunderstood action state may require clearer labels or receiver training. An unavailable authorized source may require an owner-controlled follow-up rather than a documentation rewrite.

The evaluator should retain the packet version, receiver version, test checkpoint, specific failed question and supported classification. A corrected packet is a new version. The earlier result is not erased.

This is important when the organization later reports exercise improvement. A high pass rate after sender coaching should not be described as the same outcome as independent first-attempt reconstruction.

4.21.13 Hard failures and ordinary deficiencies are not equivalent

The blind-handoff contract should have non-negotiable safety boundaries. A receiver who cites a future card at an earlier checkpoint, merges Branch S and P, invents approval or execution, declares full recovery despite P1/C1/V1 failures, or recommends an unapproved live change has failed even if every other paragraph is well written.

Other deficiencies are more localized but still matter: missing a source locator, omitting a next owner or leaving out a review trigger can prevent a new responder from safely continuing the case. These require correction but do not necessarily reveal the same misunderstanding as an unauthorized-action proposal.

The learning test therefore uses two layers. First, detect critical breaches of source release, action history and authorization. Second, assess completeness of the remaining required fields and the receiver's reconstruction. A passing packet needs both.

This does not change Module 4's existing six-output 0–2 rubric. That rubric still totals 12 across timeline, hypothesis table, action record, recovery plan, internal status message and improvement ticket. The blind test is a validation attachment, not a seventh scored output.

A packet can score highly in its six documentation categories and still fail blind reconstruction. That distinction is the principal instructional contribution of this supplement.

4.21.14 Wrong worked handoff

Incorrect synthetic summary at a later Branch S checkpoint:

"The incident lead revoked the account at 09:37 and the problem is fixed. The service has recovered, the backup passed, and the new shift can close the ticket. All evidence is somewhere in the logs."

This confuses the 09:37 proposal with the later 09:45 branch report and broadens a specific session action into an unspecified account revocation. It claims recovery without addressing the B19/B20 mismatch or V1's blank audit actor. It also lacks usable source pointers and responsible owners.

The sentence "all evidence is in the logs" does not tell a new responder where to find R17, the relevant branch card, the approved P1 target, C1 comparison or V1 audit result. A reader may know that the sentence is unsafe, but cannot repair it without consulting the actual permitted sources.

A receiver should refuse to accept the stated closure, record why the source claims fail and request an owner-approved next step. The safe answer does not require inventing an alternative attacker story or recovering a missing source through unauthorized access.

If the handoff was already frozen, the sender cannot make it retroactively correct by saying "I meant only the current session." The correction belongs in a new version with specific evidence and scope.

4.21.15 Correct worked handoff

Correct bounded synthetic Branch S summary after the separately released P1/C1 and V1 cards:

"Case HL-IR-001: At the 09:37 Round C checkpoint, R17 and R18 supported reviewing an unexplained B20 edit outside the known approved training list; the bounded session response was proposed then. Branch S later reports revocation of the identified current desk-a session at 09:45, staff reauthentication and a quiet result only inside the branch's query range. Other routes, the human operator and current technical state beyond that report remain unverified. The later P1/C1 comparison shows B19/B20 inconsistent with the approved targets; V1 has limited access passes but a failed actor-attribution field. Full service acceptance is not established. The service owner should decide on a bounded correction request and new comparison; the application/audit owner should repair and retest attribution; the lead reconvenes on a verified unexplained edit or failed retest."

The receiver can locate R17/R18 in Module 3, Branch S in Module 4 and P1/C1/V1 through their later Module 3 teaching cards. The wording distinguishes proposal, reported execution, known test limits and proposed correction. It also does not treat the source set as proving real production recovery.

For an equally defensible Branch P packet, replace the session report with the pause and two pending manual items at 09:45. The service owner must still decide whether or when writes resume and how the queue is reconciled. Never mix the two alternative reports in one chosen branch history.

The packet's adequacy is still subject to an independent receiver test. A model answer written by the author is not evidence that another participant can reconstruct it unaided.

4.21.16 Use failed reconstruction to improve the actual packet

The blind exercise should conclude with a short, evidence-linked improvement task. If the receiver incorrectly called the 09:37 proposal executed, specify whether the packet lacked action-state labels or the receiver misinterpreted a clear source. If the receiver could not locate C1, verify whether the manifest contained a working source pointer. If the receiver recommended immediate production correction, check whether the packet clearly marked owner approval as required.

A good improvement ticket has one observed failure, its frozen packet and receiver answer, an owner, a proposed correction, a retest and a pass/fail condition. An example is:

• Observed defect: receiver treated the Branch S report as evidence that every session and booking path remained secure.
• Packet change: add a separate last-reported action and current-effect-unknown field, with the branch card pointer.
• Retest: give the revised sealed packet to a different participant or conduct a separately labeled second round under the same declared checkpoint.
• Pass: receiver independently reports the specific last action, its limits, the failed later gates and the next approval request.
• Fail: receiver still declares full recovery or proposes an unapproved action.

This turns a vague recommendation to "improve handoffs" into a specific capability test. NIST SP 800-84 and FEMA's exercise-evaluation guidance support the broader practice of documenting observed exercise performance and corrective actions; the exact card and thresholds here are OpenCyber Academy's own.

4.21.17 A passing tabletop does not measure real incident capability

The BH4 program checks invented dictionaries, not actual source provenance, live systems or human comprehension. An ordinary participant could correctly answer all six questions in a quiet classroom and still struggle with missing evidence, inaccessible sources or time pressure during an actual event.

A valid exercise report therefore distinguishes structural packet validity, human reconstruction performance and operational control verification. The first can be assisted by a small script. The second requires an observed independent human answer. The third would need appropriate organizational authorization, technical sources and safe tests outside this fictional course.

The exercise should record these boundaries explicitly. A successful BH4 script does not authenticate a GitHub link, execute a write pause, verify an identity provider, fix booking values or certify a backup. A student may use the script to predict failure categories but must still produce a real written reconstruction to demonstrate the intended skill.

An instructor should not turn the classroom score into an accreditation claim. OpenCyber Academy is a learning collection; the materials develop reasoning through controlled and auditable practice.

4.21.18 Section synthesis and next learning step

The essential outcome is an independent receiver who can continue a case safely. The receiver must identify the checkpoint, select the right branch, locate permitted evidence, distinguish proposed from reported executed actions, mark failed and untested service criteria, request the next owner-approved action and identify what would trigger a new decision.

A handoff without those properties may be readable but incomplete. A detailed handoff that falsely declares recovery may be more dangerous than a concise one that exposes the gaps. The safest transfer preserves source pointers, uncertainty and decision authority rather than hiding them inside a polished narrative.

This lesson does not alter the canonical Harbor Library timeline or any already released fixture. It adds a reproducible exercise that makes the sender's documentation and the new receiver's unaided understanding observable and correctable.

4.22 BH4 offline laboratory — reconstruction state and negative controls

Classification: Entirely synthetic, independent BH4 teaching fixture. It is not R1–R24, Branch S/P, P1/C1, V1, F1, F4-AUDIT, L2, DEL4 or an observed production handoff.

Goal: Verify the internal structure of a frozen packet and an invented receiver answer. Reject later evidence used prematurely, mixed branches, missing source pointers, action-state rewrites, recovery overclaims, absent owners, unsafe steps, missing triggers and a receiver misunderstanding.

Environment: Python 3 standard library, memory only. No network calls, credentials, files, messaging, service changes or real evidence access.

Fixture scope: The baseline is a fictional Branch S reconstruction after P1/C1 and V1 have been separately released. It keeps Round C action status PROPOSED, the later Branch S 09:45 status REPORTED, and the present technical effect NOT_INDEPENDENTLY_VERIFIED. Its data and audit gates remain failed. A separate valid Branch P variant uses the other mutually exclusive branch. The exact strings are classroom assertions, not authenticated operational receipts.

Complete Python 3 code

from copy import deepcopy

STAGES = {
    "A": 1, "B": 2, "C": 3,
    "D_BRANCH": 4, "D_TARGET": 5, "D_ACCESS": 6,
}
RELEASE = {
    **{f"R{i}": "A" for i in range(1, 9)},
    **{f"R{i}": "B" for i in range(9, 17)},
    **{f"R{i}": "C" for i in range(17, 25)},
    "S": "D_BRANCH", "P": "D_BRANCH",
    "P1": "D_TARGET", "C1": "D_TARGET",
    "V1": "D_ACCESS",
}
ROOT = "MANUSCRIPT.md#"
LOCATOR = {
    "R17": ROOT + "ch-03", "R18": ROOT + "ch-03",
    "S": ROOT + "ch-04", "P": ROOT + "ch-04",
    "P1": ROOT + "ch-03", "C1": ROOT + "ch-03",
    "V1": ROOT + "ch-03",
}
BASE = {
    "checkpoint": "D_ACCESS",
    "branch": "S",
    "refs": ["R17", "R18", "S", "P1", "C1", "V1"],
    "locators": {
        key: LOCATOR[key]
        for key in ["R17", "R18", "S", "P1", "C1", "V1"]
    },
    "C_action": "PROPOSED",
    "D_report": "SESSION_REVOKED_REPORTED_0945",
    "current_effect": "NOT_INDEPENDENTLY_VERIFIED",
    "data_gate": "FAIL_B19_B20",
    "audit_gate": "FAIL_ACTOR",
    "full_service": "NOT_ACCEPTED",
    "next_action": "REQUEST_CORRECTION_PLAN_AND_RETEST",
    "next_owner": "ServiceOwner",
    "next_authority": "OWNER_APPROVAL_REQUIRED",
    "revisit_trigger": "VERIFIED_NEW_EDIT_OR_FAILED_RETEST",
    "receiver": {
        "branch": "S", "C_action": "PROPOSED",
        "D_report": "SESSION_REVOKED_REPORTED_0945",
        "current_effect": "NOT_INDEPENDENTLY_VERIFIED",
        "data_gate": "FAIL_B19_B20",
        "audit_gate": "FAIL_ACTOR",
        "full_service": "NOT_ACCEPTED",
        "next_action": "REQUEST_CORRECTION_PLAN_AND_RETEST",
        "next_owner": "ServiceOwner",
    },
}

def inspect(p):
    refs = set(p["refs"])
    if (
        {"S", "P"}.issubset(refs)
        or (p["branch"] == "S" and "P" in refs)
        or (p["branch"] == "P" and "S" in refs)
    ):
        return "FAIL_BRANCH_MIX"
    if p["branch"] not in {"S", "P"} or p["branch"] not in refs:
        return "FAIL_BRANCH_NOT_GROUNDED"
    bad = sorted(
        ref for ref in refs
        if ref not in RELEASE
        or STAGES[RELEASE[ref]] > STAGES[p["checkpoint"]]
    )
    if bad:
        return "FAIL_FUTURE_OR_UNKNOWN:" + ",".join(bad)
    no_link = sorted(
        ref for ref in refs if not p["locators"].get(ref)
    )
    if no_link:
        return "FAIL_MISSING_POINTER:" + ",".join(no_link)
    if (
        p["C_action"] != "PROPOSED"
        or p["D_report"] != {
            "S": "SESSION_REVOKED_REPORTED_0945",
            "P": "PAUSE_REPORTED_0945",
        }[p["branch"]]
    ):
        return "FAIL_ACTION_HISTORY"
    if p["current_effect"] != "NOT_INDEPENDENTLY_VERIFIED":
        return "FAIL_CURRENT_STATE_OVERCLAIM"
    if (
        p["data_gate"] != "FAIL_B19_B20"
        or p["audit_gate"] != "FAIL_ACTOR"
        or p["full_service"] != "NOT_ACCEPTED"
    ):
        return "FAIL_RECOVERY_OVERCLAIM"
    if not p["next_owner"]:
        return "FAIL_NO_OWNER"
    if (
        p["next_authority"] != "OWNER_APPROVAL_REQUIRED"
        or p["next_action"] != "REQUEST_CORRECTION_PLAN_AND_RETEST"
    ):
        return "FAIL_UNAUTHORIZED_NEXT_STEP"
    if not p["revisit_trigger"]:
        return "FAIL_NO_TRIGGER"
    for key in (
        "branch", "C_action", "D_report", "current_effect",
        "data_gate", "audit_gate", "full_service",
        "next_action", "next_owner",
    ):
        if p["receiver"].get(key) != p[key]:
            return "FAIL_RECEIVER_RECONSTRUCTION:" + key
    return "PASS_BOUNDED_RECONSTRUCTION"

VARIANTS = [
    ("BASE_S", {}),
    ("FUTURE_CARD", {"checkpoint": "D_BRANCH"}),
    ("MIXED_BRANCH", {"refs": BASE["refs"] + ["P"]}),
    (
        "MISSING_POINTER",
        {
            "locators": {
                k: v for k, v in BASE["locators"].items()
                if k != "C1"
            }
        },
    ),
    ("REWRITE_ROUND_C", {"C_action": "REPORTED_EXECUTED"}),
    ("CROSS_BRANCH_REPORT", {"D_report": "PAUSE_REPORTED_0945"}),
    ("CLAIM_FULL_RECOVERY", {"full_service": "ACCEPTED"}),
    ("NO_NEXT_OWNER", {"next_owner": ""}),
    ("UNSAFE_ACTION", {"next_action": "RESUME_WRITES_NOW"}),
    ("NO_REVIEW_TRIGGER", {"revisit_trigger": ""}),
    (
        "INCORRECT_RECEIVER",
        {"receiver": {**BASE["receiver"], "D_report": "PROPOSED"}},
    ),
]

for name, changes in VARIANTS:
    p = deepcopy(BASE)
    p.update(changes)
    print(name, inspect(p))

# A separate valid Branch P choice, not a combined branch.
p = deepcopy(BASE)
p["branch"] = "P"
p["refs"] = ["P" if v == "S" else v for v in p["refs"]]
p["locators"] = {
    "P" if k == "S" else k: v
    for k, v in p["locators"].items()
}
p["D_report"] = "PAUSE_REPORTED_0945"
p["receiver"] = {
    **p["receiver"],
    "branch": "P",
    "D_report": "PAUSE_REPORTED_0945",
}
print("BASE_P", inspect(p))

Compare your run with the worked BH4 transcript and limitations after recording predictions.

Practice and submission

Negative experiment: Change only the receiver's D_report value and observe FAIL_RECEIVER_RECONSTRUCTION:D_report; restore it to the reported branch status for the baseline. Alternatively, remove C1's manifest pointer and observe FAIL_MISSING_POINTER:C1. Never treat a missing pointer as proof that the booking comparison passed.

Required lab submission: Twelve output lines, a per-variant failure table, the identified source-release boundary, a one-paragraph distinction between packet validity and independent human reconstruction, and a proposed next safe request for each selected branch.

4.23 Two-role practical — a handoff without the author

Roles: Sender and Receiver. A facilitator may evaluate them separately but is not required for the basic two-role activity. All notes concern fictional records only.

Goal: Determine whether the receiver can reconstruct the case and select a safe action without the sender explaining or correcting the packet.

1. Declare the stage and branch. Choose the first Branch D checkpoint or the later D checkpoint after P1/C1/V1; explicitly restrict inputs accordingly. Use only Branch S or only Branch P.
2. Sender prepares the packet. Include case ID, release ledger, frozen Round C proposal, selected reported branch, available source pointers, known failed/unknown acceptance criteria, responsible owners and review trigger. Retain the existing six chapter outputs.
3. Freeze sender version. Save it as BH4-packet-v1 with a declared classroom checkpoint. The sender must not silently modify it while the receiver works.
4. Receiver works alone. Provide the packet and the permitted synthetic source cards. The sender gives no hints. The receiver writes the six reconstruction answers in §4.21.11 using exact record and card identifiers.
5. Freeze receiver answer. Save BH4-receiver-v1. The receiver must explicitly state any unlocatable source or uncertain action status rather than guess.
6. Adjudicate against sources. Compare the two frozen artifacts with the permitted R-series and cards. Distinguish sender omissions, receiver mistakes and unavailable evidence. Apply the critical safety failures before any ordinary completeness score.
7. Choose the next safe action. The receiver identifies the owner-approved correction/retest or, for Branch P, queue-disposition request and resumption condition. The response cannot itself execute a system change.
8. Retest with a new version if necessary. Keep the failed original; submit a new packet version and separately frozen reconstruction so improvement can be measured.

Pass: The receiver finds the source-supported checkpoint, one branch, proposal/report distinction, failed or unknown gates, next approval owner and trigger; no future cards, invented completed correction or unauthorized action appear.

Fail: A critical release or branch error, fabricated approval/execution, unsupported recovery claim or unsafe next action is present. A missing source locator, owner or trigger also blocks a fully satisfactory reconstruction, with a specific fix recorded.

Evidence to retain: Sender packet, receiver first answer, source-locator checklist, failed/passed conditions, reviewer explanation and any later version history. These are supplementary test materials, not new numbered exercises or real incident artifacts.

4.23a A good tabletop score must survive a frozen-evidence audit

Learning objective: Distinguish a participant's documented decision from the facilitator's intended storyline and from the end-of-exercise model answer. Before scoring, identify which cards and independently produced receipts the learner could see at the assessed checkpoint. An excellent final narrative cannot repair a contaminated early decision without preserving both versions.

The facilitator release ledger records the permitted inputs for Round A (R1–R8), B (R1–R16), C (R1–R24), and the separate Round D branch, P1/C1 and V1 phases. The participant artifact records what the learner actually wrote and submitted. The observer note records what the facilitator witnessed: an approval explicitly role-played, a question deferred, a source unavailable, or a packet that could not be reconstructed by a new responder. These three records serve different purposes. A printed solution can show a defensible choice, but it cannot prove that the participant made that choice at the right time.

Contrastive example A — L2 after all releases: The original L2 packet's timeline, Round B hypotheses, Round C action, recovery note, late status and improvement item reconcile to 2 + 2 + 1 + 0 + 2 + 1 = 8/12. The recovery claim is contradicted by C1's B19/B20 mismatches and V1's blank audit actor; its zero is not made harmless by a later excellent status. A facilitator should return a specific revision request and retain the original scored version. The passing threshold of 9/12 and the critical-zero rules are OpenCyber Academy classroom criteria, not a NIST recommendation. A new D-recovery-v2 may earn a new grade but does not alter the earlier snapshot.

Contrastive example B — EX048 at 09:45: EX048's two-sentence update uses only the chosen Branch S or P report at 09:45, before the later P1/C1 and V1 releases. An otherwise accurate sentence saying “V1's audit actor failed” would be premature in EX048, even though it is appropriate in L2's later all-cards status. Likewise, EX043 at Round B may contain a proposed preservation request, not a finished collection. A learner's claim that “the lead approved it, so the copy exists” lacks an object ID, collector/time, bounded source query and integrity/custody receipt. The proper grade is not “done”; record precisely which evidence state has not been observed.

This is why both artifact quality and exercise validity must be reviewed. If a facilitator revealed P1 early, the observer should mark the affected round contaminated and conduct a fresh frozen checkpoint rather than awarding retrospective credit to a decision influenced by future evidence. A tabletop is a discussion-based exercise; NIST SP 800-84, Section 4.5, p. 4-5 explains that participant debrief comments, evaluator observations and recommendations belong in an after-action report. It does not certify Harbor Library's grading scale or measure a production security control. A separate authorized functional test would be needed to establish system behavior.

R4X offline lab — score an artifact and reject invalid evidence separately

Safety and data: Python 3 standard library, entirely in memory; no access to sources, mail, cloud accounts or real service actions. Each input is an invented reviewer declaration. claimed_collected and receipt_present refer only to a proposed classroom preservation assertion, not a verified Harbor Library artifact.

def grade_packet(scores, late_card_in_early, claimed_collected, receipt_present):
    if late_card_in_early:
        return "REJECT_EARLY_EVIDENCE"
    if claimed_collected and not receipt_present:
        return "REJECT_UNSUPPORTED_COLLECTION"
    if len(scores) != 6 or any(x not in (0, 1, 2) for x in scores):
        return "INVALID_RUBRIC"
    return ("PASS" if sum(scores) >= 9 and scores[2] > 0 and scores[3] > 0
            else "FAIL") + "_TOTAL_" + str(sum(scores))

cases = [
    ("L2", [2, 2, 1, 0, 2, 1], False, False, False),
    ("FUTURE_IN_EX048", [2, 2, 2, 2, 2, 2], True, False, False),
    ("REQUEST_NOT_COPY", [2, 2, 2, 2, 2, 2], False, True, False),
    ("SYNTHETIC_PASS", [2, 2, 2, 1, 2, 1], False, False, False),
]
for name, scores, late, claim, receipt in cases:
    print(name, grade_packet(scores, late, claim, receipt))

Exact tested transcript:

L2 FAIL_TOTAL_8
FUTURE_IN_EX048 REJECT_EARLY_EVIDENCE
REQUEST_NOT_COPY REJECT_UNSUPPORTED_COLLECTION
SYNTHETIC_PASS PASS_TOTAL_10

Negative controls: The fictitious perfect-looking score in FUTURE_IN_EX048 is rejected for using information not released at the assessed checkpoint. The similarly high REQUEST_NOT_COPY is rejected because the answer asserts completed collection without a receipt. A mathematical passing score cannot cancel either integrity failure. SYNTHETIC_PASS reflects only consistent reviewer-entered fixture values, not proof of real participant performance or verified system readiness.

Activity: The participant submits the exact four lines, the six-field L2 score table, a separate one-line 09:45 EX048 release rule, and one narrowly scoped follow-up request for an EX043 copy that is still uncollected. The observer must say which failure is a missing participant answer, which is a contaminated exercise, and which is simply absent evidence. Full credit requires keeping Round C approvals separate from later Branch S execution, no invented collection, and a versioned correction after rather than inside the scored original.

Chapter synthesis: Harbor Library can teach an honest handoff without closing its fictional incident. A successful participant outcome is a reproducible decision under released evidence, plus clear owners and tests for unresolved data, audit and service gates—not a dramatic story of recovery. The book's final exercise result must not be treated as evidence of what a learner actually did.

Worked checkpoint

The next analyst should reconstruct the evidence boundary and outstanding decisions from a sealed packet without coaching from its author. If they cannot identify the current owner or pending approval, the handoff is incomplete even when the original author understood the case.

Practice — Lesson 20

EX050 — Final handoff and self-assessment

Objective: give a new responder a complete, auditable state without overstating closure. Inputs: all rounds, one chosen branch, P1/C1, V1 and the section 4.5 rubric and L2 calibration. Output: a one-paragraph handoff naming case and evidence, proposal versus branch-reported action and fictional approvers, current booking and audit failures, unresolved cause, owners, next review and rollback trigger. Add a six-row self-score (0–2 per tabletop output, maximum 12), identify the weakest output and write one contested-score note: which artifact a second reviewer might score differently, which exact supplied record or missing field resolves the disagreement, and what revision should be versioned rather than silently replacing an earlier round. A score of 2 requires a defensible score explanation and no zero for approval or evidence scope; the handoff must distinguish the branch result from unexecuted correction or restore work.

DEL4 extension: Add an unconfirmed coordination-receipt row to the handoff, its accountable owner and a future authorized channel/read-back test. Do not change the six-output scoring denominator or present a missing reply as consent.

BH4 validation attachment (separate from the six scored outputs): Preserve a frozen sender packet and unaided receiver version, declared checkpoint and branch, permitted source inventory, proposal versus branch-report state, failed gates, next safe request, approval owner, reassessment trigger and independent reconstruction result. Version a correction after feedback; do not backdate it or add a seventh score.

Worked answer: EX050 in the final appendix.

Continue studying — lesson 20 of at least 20

← Lesson 19 · Course lesson index · Next course via lesson index →

This is the last published daily lesson in the current sequence. Use the course index to reach the next English course.

Continue studying — chapter 04 of 04

← Chapter 03 · Course lesson index · Next course via lesson index →

This is the last weekly chapter in the current sequence.