Chapter 01 — Incident readiness, roles and authorized scope

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

Module map

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

flowchart TD
  N0["Learning outcomes"]
  N1["1.1 Response is part of risk management"]
  N2["1.2 A fictional service map"]
  N3["1.2a Normal booking behavior and service invariants"]
  N4["BSL1 offline laboratory — booking invariants"]
  N5["1.2b Essential service paths and degraded modes"]
  N6["1.3 Roles and decision authority"]
  N7["1.3a Rehearsing authority before an incident"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Module logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["1.1 Response is part of risk management"]
  N2["1.2 A fictional service map"]
  N3["1.2a Normal booking behavior and service invariants"]
  N4["BSL1 offline laboratory — booking invariants"]
  N5["1.2b Essential service paths and degraded modes"]
  N6["1.3 Roles and decision authority"]
  N7["1.3a Rehearsing authority before an incident"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]

[Learning outcomes]
    |
    v
[1.1 Response is part of risk management]
    |
    v
[1.2 A fictional service map]
    |
    v
[1.2a Normal booking behavior and service invariants]
    |
    v
[BSL1 offline laboratory — booking invariants]
    |
    v
[1.2b Essential service paths and degraded modes]
    |
    v
[1.3 Roles and decision authority]
    |
    v
[1.3a Rehearsing authority before an incident]
    |
    v
[Worked example] --> [Exercise EX013]

Module learning outcomes

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

1. Explain why incident response begins before an alert appears and continues after service recovery.
2. Distinguish an observation from an interpretation, a response decision and a confirmed fact.
3. Identify the service owner, response lead, analyst, recovery lead and communications contact for a small incident.
4. Define the scope and authorization for a contained response exercise.
5. Open an incident record with a timeline, evidence pointers, uncertainty and decision ownership.
6. Describe a safe first action when a suspicious signal has not yet been verified.
7. Turn a service dependency map into a bounded evidence-readiness plan without treating a planned log source as a collected fact.

Shared Round A case packet

The following eight rows are synthetic classroom inputs for Lessons 01–05 in Chapter 01. Section 1.7 later explains their provenance and limits; this preview makes the same packet available before the first daily exercise. All times are UTC on 2026-10-11. A row reports source content, not a proved cause or human identity.

Lesson table; scroll horizontally to read all columns →

Module 1 exercise rules

Work from only R1–R8 and the fictional authority rules in Module 1. The case is synthetic. At the 09:00 intake and 09:05 decision checkpoints, do not cite records or interviews released in later chapters, claim a production collection took place, or infer a person's identity from an account label. Write any imagined future signal as hypothetical. For each answer: (1) write HL-IR-001 and the exercise ID; (2) copy the relevant record IDs and UTC times; (3) fill the named output fields; (4) mark each conclusion as observed, inferred, unknown or proposed; (5) name an owner and approval for any new collection or service change; and (6) compare the result with the worked answer at the end of the book. The submitted table, note or decision card is the expected evidence of learning; a label without its supporting record is insufficient.

Common assessment rubric: score an exercise 0 if its artifact is missing or presents an unsupported attribution or action as fact; 1 if it answers the question but omits a required source, limit, authority or test; 2 if all named fields are present, the reasoning follows the supplied evidence and the next step is bounded and authorized. The local requirements below specify what earns 2 points. A claimed compromise, successful restore or absence of data transfer based only on R1–R8 must be corrected regardless of the numerical score. No real website, account or patron data is needed.

Lesson 01 — Evidence readiness and the first case question

Week 1, 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.

1.1 Response is part of risk management

An incident response team does more than react to an alarm. It prepares contacts and authority, recognizes potentially harmful activity, preserves facts, makes proportionate decisions, restores services and learns from the result. NIST SP 800-61 Rev. 3 places incident response recommendations throughout cybersecurity risk management as described by the NIST Cybersecurity Framework 2.0. The framework's Govern, Identify, Protect, Detect, Respond and Recover functions are concurrent and continuous activities. A team should not wait for “Respond” to think about owners, backups, communications or evidence.

There is an important distinction between a function used to prepare for response and an action taken during a particular case. The model in NIST SP 800-61 Rev. 3, section 2.1 places Govern, Identify and Protect in broad preparation and risk management; Detect, Respond and Recover describe the case-facing response activities. Its improvement category connects lessons back to all of them. This is a model for organizing outcomes, not a requirement that every case move through six isolated steps. In Harbor Library, naming an authorized service owner belongs to readiness; checking today's booking edit belongs to investigation; deciding whether to restrict an account belongs to response. An improvement ticket after the exercise may change the owner's contact list before the next case.

A beginner can test readiness with four questions: What service might be harmed? Which records could show what happened? Who may approve a disruptive action? What result would show that normal service is safe to resume? A team that cannot answer them has work to do even if its alerting system is excellent. Conversely, answering them does not establish that a particular alert is malicious. The distinction prevents a control inventory from being mistaken for an incident finding.

Consider a small library that provides room reservations online. An alert may say that an administrator account signed in at an unusual hour. That is a signal worth examining. It does not by itself prove account compromise. A change to the reservation database may be an event with business effect. The team must assess context, evidence and impact before it labels the situation a confirmed incident. These are working definitions for this teaching case; an organization should use its own approved classification policy.

The first useful question is: Which service and people could be harmed, and what is known right now? A team that records uncertainty can act quickly without pretending to know a root cause. A team that labels every alert “breach” risks needless disruption; a team that dismisses every alert risks delayed containment.

1.2 A fictional service map

The course uses Harbor Library, a fictional organization. No personal records or real network are involved. Residents reserve study rooms through a website. Front-desk staff can edit bookings. A separate event-newsletter list contains contact addresses. The booking service depends on a web application, an identity service, a database, a nightly backup and a staff help desk.

Lesson table; scroll horizontally to read all columns →

This map is incomplete on purpose. It does not say whether the application uses third-party hosting, how clocks are synchronized, or who can approve a service outage. A response team should record those as readiness gaps before a crisis. If one dependency fails, the team can then ask the correct owner for evidence and options.

From dependency map to evidence-readiness contract

A service map names components and owners; it does not show that an investigator could answer a specific question on time. A useful next step is an evidence-readiness contract: a short, testable agreement about which source would record an event, what its fields mean, who may retrieve it, how long a useful record can remain available and how a second analyst could reproduce the selection. This is a OpenCyber Academy teaching device, not a required form from NIST SP 800-61 Rev. 3. NIST's incident-response guidance places preparation, service knowledge and response roles within broader risk management; the contract below turns that general orientation into a small fictional library exercise.

Begin with a decision question, rather than a product name. The practice records introduced in section 1.7 will include a cancelled booking B18 and the desk-a account; treat them as a preview here. “Do we have logs?” is too broad. “Was the B18 cancellation an approved staff action, and did the current booking state reflect it?” separates an activity question from a business-state question. A booking audit could record an edit, but an authoritative state comparison would be needed to confirm what users can book now. Similarly, an identity service could report that the account desk-a signed in, while neither the account label nor a timestamp identifies the human at the keyboard. The evidence plan should say what a source can discriminate and which tempting conclusion it cannot carry.

For each question, write six fields before the incident: (1) the producer and event it is supposed to emit; (2) identifiers that might connect records without silently merging different people or actions; (3) event time, collection time and clock or timezone assumptions; (4) the custodian, approved collection path and access limit; (5) expected retention and failure indicators; and (6) a small authorized rehearsal that could show whether the source actually works. Blank or untested fields remain unknown. A diagram that shows a log arrow without these details is an architectural hypothesis, not proof of coverage.

The following is a proposed D1 design card, written for an isolated training version of Harbor Library. It is a plan for what owners would test, not a new R-series record, a description of the library's actual logging configuration or evidence available at the 09:05 checkpoint. Field names such as request_id and session_id are candidate design fields; their existence and semantics must be checked before a real correlation.

Lesson table; scroll horizontally to read all columns →

The four-row card is a summary, not a completed six-field contract. For the first row, a fully specified proposed test record would read as follows. Its field names, times and expected observations are invented for a future isolated rehearsal; none is claimed to exist in R1–R8.

Lesson table; scroll horizontally to read all columns →

The four-row decision card is deliberately two-sided. It names a source, then names what would still be unknown after seeing it. That prevents the familiar slide from “log exists” to “question answered.” Its first row also distinguishes an activity record from a state-of-the-world record. If an application audit says B18 was cancelled but the restricted current-state copy is missing, the analyst can report the recorded cancellation and request the state comparison. The analyst cannot certify the live schedule from the audit alone. Its second row anticipates Module 2's correlation exercise: even a supplied exact session-key match narrows a record relationship, not the identity or authorization of a person.

Trace where an observation could be lost. A missing search result has several different causes. The producer might never emit the event; an emitted event might fail collection; a collected record might arrive after the query; an available record might already have aged out; access controls might deny the selected view; the query might use the wrong booking ID, timezone or time window; or a reviewer might misread a real row. The response to these failures differs. Repeating the same query cannot repair non-emission, and asking for a broad export is not a substitute for fixing a wrong filter. A readiness review therefore records the last confirmed point in the path from producer to learner and a named owner for the next check. Do not collapse every empty result into “the system had no activity.”

Make a rehearsal falsifiable. In an isolated, explicitly approved training copy, an owner could predeclare one synthetic booking change and one deliberately out-of-range control event. The application custodian would record the test request ID and UTC event time; the collector would record receipt time and source; the analyst would run a bounded query and save the exact filter and run time. The expected result is the in-range change and its agreed fields, with the out-of-range control excluded by the declared interval. If the expected row is missing, the team investigates emission, transport, retention, access and query scope in order. If the out-of-range row appears, the filter or time interpretation needs correction. Passing this small rehearsal shows only that the tested path and interval behaved as stated. It does not prove all future events will be collected, or that the event proves why a person acted.

Rehearsal evidence should include the negative and failure cases, not only a successful dashboard screenshot. A copy of a search result without its source, filters and collection boundary may be impossible to reproduce. A source timestamp and an analyst's discovery time should occupy separate fields; otherwise a delayed record can seem to have happened later than it did. The plan should also say how a source error is noticed: for example, a missing expected test event, a delayed collection receipt, a schema change or an expired retention window. Module 2 will exercise those distinctions with synthetic records. They belong in readiness because a responder cannot reconstruct a record that was never retained.

Scope and privacy follow the question. The booking question does not authorize opening the separate newsletter list. The D1 card names minimal booking and session fields to request, the custodians who could provide them and the approval to seek. If a later, supported observation raises a data-exposure concern, the incident lead and privacy contact can define a new purpose and boundary. Collecting an entire identity history or patron database merely because it is technically accessible would enlarge the case and the number of people exposed to those records. A good evidence plan makes the smallest useful selection reproducible and records what it excluded. The exact retention, access and privacy rules of a real organization must come from its own policy and applicable obligations; this fictional card does not supply them.

After reading the dataset in section 1.7, apply the contract to the actual Module 1 snapshot without importing D1 as evidence. R1 reports a desk-a sign-in, but no device, session-key semantics or person. R3 and R4 record booking edits, but the supplied table does not contain an owner-approved target or a fresh authoritative state comparison. R5 records a patron's report, not a count of all affected users. R6 schedules training, but does not list the approved booking tasks. R7 reports a completed backup job, not an isolated restore. R8 explicitly lacks destination detail, so it cannot establish absence of data transfer. At 09:05 the analyst can open a bounded case, preserve the supplied pointers and ask the named owners for the missing discriminators. The analyst cannot claim that the proposed D1 logging fields or rehearsals were already implemented.

An evidence-readiness contract is useful only if someone owns its maintenance. A service change may rename a booking field, split a write path, move a log producer or shorten retention. The owner would then re-run the authorized test and update the contract's source, meaning and collection route. The document should show its last tested scope and next review trigger; an old “green” status without those details is weaker than a current, explicit unknown. This connects Module 1's service map to Module 2's evidence handling, Module 3's control and recovery checks and Module 4's after-action improvements. It remains a preparation artifact, not a substitute for case evidence or a completed investigation.

Test whether readiness is usable

A response team may possess a policy, a contact list, monitoring software and nightly backups while still being unable to make a safe decision under pressure. The existence of a component says little about whether the team can use it correctly when a particular service is threatened.

A practical readiness claim should have five parts: capability, owner, permission, test, and failure response. For example, "we have booking logs" is an inventory statement. A verifiable readiness statement is: "the application custodian can, with the incident lead's approval, retrieve booking changes for a specified identifier and time interval; another reviewer can check the source, filters and output; if the expected test row is absent, the custodian investigates collection and retention rather than claiming no activity occurred."

This distinction matters because apparent technical success can hide failed business outcomes. A green web-health indicator may represent a responsive landing page while a reservation write fails. A successful backup-job status does not demonstrate that a restored database contains the correct schedule. A sign-in record establishes that the producing system reported an account event; it does not establish a human identity.

NIST Cybersecurity Framework 2.0 describes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond and Recover. NIST SP 800-61 Revision 3 integrates incident-response recommendations with organizational risk management. Neither source authenticates Harbor Library's fictional observations or specifies this exercise's cards. The teaching implication is to examine whether the organization's desired outcomes can actually be demonstrated.

Consider the following contrasting rehearsal results:

Lesson table; scroll horizontally to read all columns →

Readiness tests should expose their own limitations. Passing one retrieval rehearsal validates the tested path and interval, not every collector, account or future day. A signed approval for one mock change does not establish authority to make any other change.

Week 1 review unit 1 — Check the input contract before interpreting the result

Objective and distinction

These five supplementary review units extend existing Lessons 01–05; they do not create new daily lessons or replace EX001–EX050. All cases and programs use fictional or in-memory fixtures. For each executable extension, run the complete named laboratory first in a fresh Python session. For AR1, also run its request-bound approval listing before the type gate. Do not connect to production systems or treat fixture results as authorization.

After this unit, explain why a program's correct calculation can still be irrelevant to the intended incident question. Identify three separate things: the selected source version, the declared input frame, and the exact proposition being tested.

Lesson 01 already teaches an evidence-readiness contract: name a useful question, a source, a custodian, collection conditions and a rehearsal. The additional step here is to test the boundary between that contract and the input actually handed to a checker. A table can be internally well formed yet belong to a different version or omit an object required by the decision.

A source pointer identifies where the reader should look. It does not by itself establish the truth, completeness or applicability of what is found. A declared input frame states which objects the current comparison is supposed to cover. It is not evidence that the frame includes every relevant production object. A test proposition states the narrow condition the program can evaluate once those inputs are accepted.

For example, the original BSL1 program can inspect supplied booking intervals. It cannot independently determine whether an exporter omitted a booking, whether its policy was approved for the relevant service, or whether the rows describe the current incident. Those questions do not become true because the overlap function executes correctly.

A three-stage review

Accept the declared input contract?
    no -> reject or request clarification; no business pass
    yes
     |
     v
Evaluate the stated model on those inputs
     |
     v
Report the result within that scope
    + name what the source and model cannot establish

Text explanation: the first stage checks whether the input can be used under this particular contract. The second applies the declared rule. The third prevents a narrow calculation from becoming an unsupported incident finding. None of the arrows authenticates a producer, establishes authorization or supplies a missing record.

Begin by freezing the expected frame before looking at the outcome. Suppose a reviewer is given a declared six-object BSL1 frame, S01–S06. A second file contains only S01 and reports no conflict. That result might be correct for S01 alone. It cannot answer the six-object question unless the missing five objects are accounted for. Silently redefining the expected frame to match the returned file would change the question after seeing the answer.

Next inspect field meaning, not only field presence. A field called confirmed might contain a Boolean, text, an integer or no value. A value that a programming language treats as true is not necessarily an affirmative statement under the exercise's schema. Unit 4 makes that difference executable.

Finally inspect the sentence the analyst writes. Even an authentic R4 pointer supports the fact that a cancellation was recorded; it does not supply approval, the human actor or a fresh owner-approved booking-state comparison. Type checking is not semantic proof. Conversely, a malformed input is not evidence that a malicious change happened. It is a reason to stop that comparison and seek a usable source.

Worked example

A proposed review note says: “The checker returned no findings, so all six bookings are safe.” The attached input contains only S01. The first error is a frame mismatch, before any question about whether the overlap calculation is correct. The second error is promoting a fixture result into service safety. A defensible replacement is: “No overlap was found in the declared one-row comparison; this input does not answer the six-row rehearsal question or establish a real service state.”

To answer the original question, the reviewer should retain the one-row input and its result, request the missing frame or an explicit owner-approved scope revision, and rerun the relevant comparison. Do not invent the absent rows, infer that they were deleted, or overwrite the first result.

Supplementary practice W1-R1

Objective: separate input admissibility from the meaning of a computed result. Inputs: the three reports below, the original R4 limitation, and the BSL1 six-object frame described above. Required artifact: three rows containing admissibility decision, narrow supported statement, missing evidence and next bounded request. Constraints: no new R-series facts; no production collection; retain both the submitted input and its declared scope.

Lesson table; scroll horizontally to read all columns →

Assessment: one point for each correctly reasoned row, one for distinguishing a missing frame from a negative finding, and one for preserving the canonical case boundary. Five points assess this supplementary task only. A claim of real approval, human attribution or safe production state requires correction regardless of the total. Worked answer.

Review synthesis

A usable input, a correct calculation and a justified operational conclusion are different achievements. Preserve the boundary between them.

Worked checkpoint

R1 records a successful account sign-in; R3 and R4 record booking changes. The records establish sequence, while the identity of the person and approval of the changes remain unknown. The first decision is a bounded question to the owner, not a compromise verdict.

Practice — Lesson 01

EX001 — Observation or inference

Objective: separate the content of a record from an explanation of that content. Inputs: R1, R3, R4, R5 and R7, all within the R1–R8 Round A release at 09:05. These are the exact source pointers for the four statements; do not use R9 or any later case result. Output: a four-row table with statement, classification, supporting record and one sentence describing the record's limit. Classify: (a) “R4 records a cancellation of B18”; (b) “desk-a was compromised”; (c) “R5 reports that B18 disappeared”; (d) “R7 proves the service can be restored in ten minutes.” Use the categories direct observation, hypothesis requiring confirmation and unsupported conclusion. A score of 2 requires distinguishing the fact of a patron report from independent proof of the patron's full experience.

Extension: For each original statement, rewrite any unsupported conclusion into the narrowest defensible wording. Add one source that would be needed to upgrade the claim.

For full credit: A 2-point answer must distinguish "R5 records a patron report" from "the booking interface was independently proved incorrect," and "R7 reports backup completion" from "recovery was tested." Merely selecting a label without a limiting sentence earns at most 1.

Worked answer: EX001 in the final appendix.

Lesson 02 — Booking invariants and behavioral baselines

Week 1, 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.

1.2a Normal booking behavior and service invariants

What does it mean for a service to work correctly?

Incident readiness is easier to discuss when the organization can explain what its service promises to legitimate users. A web page can respond while the function behind it is wrong. For a study-room service, a patron may see a confirmation yet not obtain a valid room, or may see a cancellation while the room remains unavailable to someone else. These situations have different operational causes, but they illustrate a common preparation problem: knowing that software is reachable is not enough to specify a correct business outcome.

The current Chapter 01 identifies the booking application, staff identity service, database, backup and help desk. That service map names components and owners. Its D1 evidence-readiness contract asks which source might record a relevant event, what its fields mean and whether the team could retrieve it responsibly. The separate question developed here is: What observable condition would mean that the booking service met a defined business requirement?

A behavior baseline is a documented description of acceptable operation in a specified version and context. It might identify which reservation states are valid, when a room is occupied, whether a cancellation releases a slot, how overlapping times are handled and what should happen to an invalid request. The rule's owner must be clear. A responder should not invent the booking policy during an incident merely to make a preferred theory fit the data.

This is related to identifying important services and their consequences for organizational risk. The NIST Cybersecurity Framework 2.0 organizes ongoing cybersecurity risk management, and NIST SP 800-61 Revision 3 integrates incident-response preparation with those risk-management activities. Neither source prescribes the booking rules in this example. The rules are deliberately fictional, but the discipline of defining and testing a service outcome is reusable.

At introductory level, the learner should ask three questions: What legitimate task does the user expect to complete? What result would be unacceptable even though the application remains reachable? Which conditions must be specified before we can judge that result? A clear answer is more useful than an unexplained green health indicator.

Trace the legitimate user journey before imagining an attacker

A useful behavior baseline begins with a normal user journey. In a hypothetical Harbor Library service, a patron chooses a room and time, submits a request, receives an accepted or rejected response and later looks up the resulting booking. A permitted staff member might move or cancel that booking. The canonical R1–R8 table does not specify actual endpoints, database transaction rules or the organization's full approval workflow, so this journey is a proposed teaching model, not a verified implementation.

Break the proposed journey into small outcomes:

Lesson table; scroll horizontally to read all columns →

The table does not establish that any of these errors happened in the canonical case. It describes the questions an owner-approved rehearsal could test before an incident. The behavior criteria should be defined in words a front-desk worker can understand. If the requirement cannot be explained without the name of a programming framework or database product, it may be too tied to implementation detail to express the actual user promise.

Notice also that the positive and negative outcomes are different. Showing that one ordinary reservation succeeds does not show that an invalid overlap will be rejected. Showing that a cancellation returns a success response does not show that the correct room became available. Readiness requires a small set of independent questions, not one vaguely successful demonstration.

The journey should include its boundaries: the intended room type, the time period tested, permitted roles and what counts as a completed booking. A library might have shared rooms or provisional reservations, but those capabilities are not specified in the exercise. The learner must not assume them simply to explain an observed problem away.

Convert vague expectations into testable invariants

An invariant is a property that should stay true whenever its stated conditions apply. For a simplified single-occupancy study room, one plausible rule is that two confirmed bookings must not occupy overlapping time intervals in the same room. A second rule may be that a cancelled booking does not occupy its old slot. A third may require every accepted interval to end later than it starts.

An invariant is useful only with a complete contract:

1. Scope: Which rooms, statuses, time representation and application version does the rule cover?
2. Preconditions: What must be true before applying the rule?
3. Expected behavior: Which values are valid and which must fail?
4. Verification: What result would demonstrate compliance for the selected inputs?
5. Failure meaning: What can be concluded when the check fails, and what remains uncertain?

For the BSL1 teaching fixture, the scope is intentionally narrow: one fictional day, single-occupancy rooms, two recognized statuses and six synthetic booking objects. Other status meanings and room-sharing rules are not silently invented. The invariant applies to this model alone.

A testable rule is better than "the system should not make mistakes." For example: "Under the single-occupancy rule, no two confirmed rows with the same room may have intersecting half-open time intervals." The rule specifies both the objects and the condition. It also supplies a falsifier: one correctly interpreted pair of confirmed same-room overlapping intervals would violate the stated policy.

That finding would still not identify the cause. It might result from a programming defect, administrative action, race condition, test-data error or misuse. The invariant is about business-state consistency. A security incident finding requires a separate investigation of authorization, mechanism and impact.

This separation lets the analyst state a useful technical problem without claiming more than the evidence supports: "The supplied model contains an overlap that violates the declared occupancy rule" is defensible for the fixture; "the attacker stole a staff account and corrupted reservations" is not.

Time boundaries are part of service semantics

Room reservations are time-based commitments. If one booking uses Room A from 09:00 to 10:00 and another uses the room from 10:00 to 11:00, their time boundaries meet but do not necessarily conflict. If the first ends at 10:30, the second overlaps it. A policy must specify how it treats starts and ends.

The BSL1 lab uses half-open intervals, where the start is included and the end is excluded. In mathematical notation this is [start, end). Under this teaching convention, a 09:00–10:00 booking does not conflict with a 10:00–11:00 booking. A 09:00–10:30 booking conflicts with a 10:00–11:00 booking. A row beginning and ending at 11:00 has zero duration and is invalid.

The overlap condition for two valid intervals is: the first starts before the second ends and the second starts before the first ends. Comparing only whether start times are equal misses overlapping intervals with different starts. Treating both endpoints as inclusive creates false conflict reports for adjacent bookings under the declared convention.

These details matter operationally. An invalid time boundary can create a user-visible scheduling defect while the application is technically responsive. A discrepancy may result from ordinary implementation errors, an incorrect policy or a mismatched timezone rather than deliberate malicious behavior.

A real application would also need to define operating hours, timezones, daylight-saving transitions and cross-date reservations. The beginner lab deliberately avoids those extra dimensions by using one fixed fictional day with HH:MM times. This avoids implying that a short teaching parser is a production scheduling implementation.

Also keep booking time distinct from incident evidence time. R1 and R3 contain source-event timestamps used to understand the canonical case. The BSL1 room intervals describe times when a customer could occupy a space. One type of time is not a substitute for the other. A source event at 08:43 does not mean the reservation it changed was scheduled for 08:43.

A reservation's status changes how its interval is interpreted

Consider two records for the same room and time. If both are confirmed, the simplified policy sees a conflict. If one is cancelled, the cancelled record no longer occupies the slot under this rule. Counting every historical row as active would produce false positives; treating every unfamiliar status as harmless could hide real conflicts.

BSL1 recognizes exactly two statuses: CONFIRMED and CANCELLED. Confirmed bookings participate in occupancy comparisons; cancelled bookings do not. Other values are not mapped automatically. If a new status is introduced by a system change, the service owner must explain how it affects occupancy, and the checker must be updated under a versioned contract before a result is trusted.

A status change can be legitimate or unauthorized. The fact that the cancelled state releases a room does not prove the cancellation was approved. Nor does it establish that the user was notified or the historical audit is complete. Those require separate tests and evidence. The original canonical R4 records a B18 cancellation, but it contains no owner-approved target state and does not establish the current occupancy behavior of B18.

The status rule is therefore a preparation aid. It lets a team articulate which state would be correct if the approved conditions were known. It cannot turn a printed application event into a verified business outcome.

A useful control question is: "If the status input changes while room and time stay constant, which result should change?" The BSL1 negative variant later alters a cancelled item to confirmed and thereby introduces another overlap. This shows that the model is sensitive to the status field rather than hardcoding a preferred answer.

Approval of a business rule must be versioned

The meaning of a correct booking can change. A library might introduce shared rooms, alter operating hours, allow temporary holds or change cancellation behavior. In that situation, a test that correctly enforced last year's rule might be wrong for today's approved service.

Each baseline should therefore carry a small rulebook version and owner-approved assumptions. Suggested fields include: version, owner, effective date, affected functions, accepted statuses, room categories, time interpretation, sample allowed/forbidden inputs, tested implementation version and a review trigger. These fields define correct business behavior; they do not replace D1's logging fields or the incident response authorization matrix.

Imagine a baseline version that forbids every same-room overlap. A future version might distinguish single-occupancy rooms from a shared study space. A collision in the shared room could then be permitted according to a newly approved rule. The responsible process is to retain both versions, record why the policy changed, and retest the new rule deliberately.

Do not rewrite history by applying a future policy to an older decision without saying so. A test should report which version it checked and whether that version was applicable to the operation being examined.

In the canonical Harbor Library record, R6 only shows that front-desk training was scheduled. It does not supply a complete approved booking-rule version for B17 and B18. The learner can request the relevant business specification from the service owner but cannot assert that BSL1's rules were already active in Harbor Library's actual fictional environment.

A beginner should understand the distinction between "the program is wrong" and "our documented expectation is wrong." Those lead to different next steps. Fixing the program without confirming the policy can create a new error; revising a policy simply to excuse an unexplained failure can conceal a problem. An approved contract and reproducible test help a reviewer identify which assumption requires correction.

Baseline violations do not prove cyber compromise

A security alert and a failed business invariant can appear together or separately. Neither automatically explains the other.

Suppose an isolated checker finds two confirmed bookings overlapping in Room B. The result supports a statement about that fixture under its chosen policy. It does not show that a staff credential was stolen. Potential explanations include a logic defect, a malformed import, a manual administrative error, an out-of-date rulebook or intentional unauthorized change. Each explanation would require its own discriminator.

Conversely, an unauthorized account session may exist while every booking invariant still passes. A person might view an unauthorized record without changing a reservation. Thus the absence of a business-state problem does not prove the absence of a security problem.

This matters at the first response checkpoint. An analyst who observes a suspicious sign-in may be tempted to label any later booking error as the attacker's work. But temporal proximity is not causal proof. R1 reports a successful desk-a sign-in, R3 and R4 report booking changes, and R5 records a patron concern. At 09:05, those observations support investigation; they do not provide an authenticated explanation or a current-state comparison against a complete approved baseline.

Use a four-level vocabulary:

• Requirement specified: the service owner has defined a rule for a declared scope.
• Fixture evaluated: a controlled program has applied that rule to selected teaching inputs.
• Operational discrepancy verified: a separately authorized, trustworthy comparison shows that a live service did not meet the applicable rule.
• Security mechanism established: independent investigation connects the discrepancy to an unauthorized cause.

BSL1 reaches the second level only. R1–R8 do not prove the third or fourth through association with BSL1. Keeping these claims separate helps the response team investigate a genuine service fault promptly without automatically accusing a user or minimizing a possible security concern.

Positive tests, negative tests and control conditions

A useful readiness rehearsal should not simply seek a green result. It should show that valid input is accepted and invalid input is rejected under known conditions.

The BSL1 positive example consists of adjacent bookings. One confirmed Room A reservation ends at 10:00, and another confirmed Room A reservation begins at 10:00. Under the half-open convention, the pair does not overlap.

The primary negative example contains confirmed Room B reservations for 09:00–10:00 and 09:30–10:30. Because the intervals intersect, the checker should flag a conflict.

A second negative example is a confirmed booking with start and end both at 11:00. The room itself may be available, but the reservation has invalid duration. The overlap test must not be the sole acceptance rule.

The cancellation control checks a different assumption. A cancelled Room A 09:00–10:00 record is ignored for active occupancy. In a separate variant, changing only that status to confirmed makes it conflict with the existing active booking. The test reveals why the status meaning is essential.

A third sensitivity test removes an overlapping row from a working input. The checker now reports fewer problems. That does not mean the underlying system was repaired; it means the checker no longer sees every relevant object. In a real case, this is the risk of a filtered or incomplete current-state export.

Every one of these results needs a scope limitation. A successful adjacent-interval comparison says nothing about every room or day. A flagged overlap is not a measured patron impact. A missing overlap in an incomplete input is not proof of a safe schedule.

Distinguish contract failure, input failure and source absence

When a checker returns a problem, the learner should classify what kind of problem it is.

A contract failure occurs when an interpretable input violates the declared business rule—for example, two valid, confirmed bookings overlap in the same single-occupancy room.

An input-quality failure occurs when the supplied data cannot be interpreted under the contract. A zero-length interval, duplicate booking identifier or unknown status is not necessarily the same failure as a double booking. It may reflect malformed test data, an exporter defect or an upstream application problem.

A coverage limitation occurs when relevant records are absent from the supplied test frame. If an overlapping row is omitted, the checker may report no conflict despite the unchanged larger population. This is not a demonstration that the rule passed in the intended complete scope.

These categories should remain visible in the result. Otherwise the team may investigate application behavior when it actually needs an approved source-quality check, or it may dismiss a genuine conflict as an exporter error without evidence.

The fact that a Python assertion succeeds does not authenticate the input source. For BSL1, this is acceptable because the fixture is intentionally synthetic. A real owner-approved comparison would additionally require a declared source, complete selection, timestamps, access permissions and an authoritative current-state view. Those are separate evidence questions covered by other chapters and D1; the baseline lab does not duplicate them.

A novice should be able to explain the result in one sentence: "In the provided BSL1 data, the checker found one active room conflict and one invalid duration; its broader correctness claims are limited to the six synthetic rows and the stated policy."

A contrasting wrong and correct interpretation

Plausible but incorrect:

"R1 shows the attacker signed in. R3 and R4 show the attacker changed bookings. Our new booking test found a double booking, therefore Harbor Library suffered a confirmed attack that damaged its schedule."

This merges unrelated datasets and makes unsupported causal claims. R1 contains an account label, not a verified human identity. R3/R4 record operations without establishing their authorization. The BSL1 test uses S-series objects unrelated to the R-series case. It cannot be treated as new evidence about B17 or B18.

Defensible classroom interpretation:

"At the fictional 09:05 checkpoint, R1–R8 justify asking whether the recorded B17/B18 changes were approved and whether the patron's reported symptom corresponds to the authoritative schedule. The operator, the complete training scope and current business-state correctness remain unresolved. Separately, the BSL1 fixture demonstrates how to define and check two booking invariants on invented objects; those checks make no finding about the Harbor Library incident."

The better interpretation identifies a valid next question while preserving the source boundary. It also avoids saying that an absence of BSL1 findings would clear the account or prove that no data exposure occurred. A business invariant is one useful part of readiness, not a universal security detector.

The official NIST SP 800-34 Rev. 1 updated edition addresses evaluating systems and operations for contingency requirements and priorities. It does not define Harbor Library's booking policy or confirm any R-series event. The teaching application here is that an organization benefits from understanding critical service outcomes before disruption, rather than inventing a correctness test only after something looks suspicious.

Make the baseline portable across a service change

A rule should remain understandable when software or hosting changes. The statement "the database query returned zero rows" depends on a particular implementation and selection. The statement "two confirmed single-occupancy bookings must not overlap in the same room" expresses a business expectation that can be evaluated through different authorized test paths.

That portability supports incident readiness. If a service migrates from a monolith to separate components, its logging sources may change. Its core business promise might remain stable. A behavior baseline gives the service owner a way to recognize whether the migration still produces acceptable results; D1 must separately be updated to identify where evidence can now be collected.

Portability does not mean universality. A later service version may legitimately alter the policy. The rule therefore needs version, scope and change history. A good test can report both the expected result for the old policy and the proposed new result, without erasing the previous acceptance record.

Consider a fictional software update that changes how cancelled bookings are represented. If a baseline suddenly flags conflicts, the team should first check whether cancelled entries are being incorrectly counted as active or the effective status meaning changed. That is a question about contract and test alignment, not yet a finding of compromise.

The service owner should define the intended user outcome and approve changes to its meaning. The technical team can express and rehearse the rule in code. The incident-response team can later use the approved rule as a reference while investigating a reported service failure. None of these roles gains authority to inspect real patron data merely because a demonstration program exists.

A reporting template for the first-month learner

After a baseline rehearsal, a learner should produce a contract report, not an incident report. The document should identify its rule version, input IDs, assumed room occupancy, status semantics, interval convention, positive and negative expected results, executed or reasoned output, and the exact claims the check cannot establish.

A clear report might state:

"BSL1-v1 applies to six fictional one-day booking rows. The checker tests interval validity and same-room overlaps among confirmed bookings under half-open time boundaries. It finds S03/S04 in conflict and S06 invalid. An independent status-change variant adds an S01/S05 conflict; omitting S04 from a copied input removes one detected conflict without proving service repair. No real booking state, user, account, log source or production service was tested."

This is a useful artifact because another learner can reproduce every relevant classification from the declared input. It also keeps the failure of a toy requirement from becoming an unsupported real-world incident claim.

For a beginner, the accepted result is not complicated mathematics or a comprehensive application security assessment. It is an explanation that connects business expectation → declared assumptions → reproducible comparison → constrained conclusion. The next curricular stage can then teach how an incident-response analyst obtains trustworthy observations and separates them from hypotheses.

This report complements, rather than replaces, the existing D1 evidence-readiness contract, R1–R8 claim-review laboratory and case handoff. The tools answer different questions, and a mature readiness packet keeps those boundaries explicit.

Section synthesis: preparedness begins with an explicit promise

The service map says what systems may matter. The behavior baseline says what legitimate service is supposed to achieve. The evidence-readiness plan says which authorized sources might later support or challenge a claim. The case decision record states what the team actually knows and which next action requires approval. These are complementary artifacts with distinct purposes.

For Harbor Library, an invariant about confirmed room occupancy offers a practical example of normal behavior. It neither establishes that B17/B18 were incorrectly modified nor supplies a human actor, authorized task list, restore result or data-transfer conclusion. The canonical 09:05 judgment still relies on R1–R8 only.

A sound first-month student should finish by being able to explain why an allowed adjacent booking passes, why an overlapping confirmed pair fails, why cancellation changes occupancy, why incomplete inputs can hide a conflict, and why none of those fixture results alone proves a security incident. That is additional substantive readiness knowledge, not another retelling of the incident case.

BSL1 offline laboratory — booking invariants

Goal: Reproduce a deterministic business-invariant check for a small fictional booking set, then demonstrate how a status change or missing input changes what the checker can report.

Environment: Python 3 standard library, memory only. No file creation, network requests, authentication, personal records or production changes.

Fixture classification: The IDs S01–S06 are invented BSL1 training objects and have no relationship to canonical Harbor Library bookings B17–B20 or R1–R8.

Rules: Confirmed bookings occupy the room interval, cancelled bookings do not. Booking intervals are half-open [start, end), the end must be strictly later than the start, and simultaneous confirmed overlaps in the same room are disallowed under this toy single-occupancy policy.

Lesson table; scroll horizontally to read all columns →

Before running, predict the base findings. Explain why S01 and S02 do not overlap, and why S05 does not occupy its room slot. Then predict the outcome when S05 alone changes to confirmed and when S04 is intentionally omitted from an incomplete working copy.

Reproducible Python 3 program

from itertools import combinations

BOOKINGS = [
    ("S01", "Room A", "09:00", "10:00", "CONFIRMED"),
    ("S02", "Room A", "10:00", "11:00", "CONFIRMED"),
    ("S03", "Room B", "09:00", "10:00", "CONFIRMED"),
    ("S04", "Room B", "09:30", "10:30", "CONFIRMED"),
    ("S05", "Room A", "09:00", "10:00", "CANCELLED"),
    ("S06", "Room C", "11:00", "11:00", "CONFIRMED"),
]

def minute(text):
    hours, minutes = map(int, text.split(":"))
    if not (0 <= hours < 24 and 0 <= minutes < 60):
        raise ValueError("invalid clock field")
    return hours * 60 + minutes

def overlaps(a, b):
    return (
        minute(a[2]) < minute(b[3])
        and minute(b[2]) < minute(a[3])
    )

def inspect(rows):
    if len({r[0] for r in rows}) != len(rows):
        raise ValueError("duplicate booking ID")

    issues = []
    for row_id, room, start, end, status in rows:
        if status not in {"CONFIRMED", "CANCELLED"}:
            issues.append(f"UNKNOWN_STATUS {row_id}")
        if minute(start) >= minute(end):
            issues.append(f"INVALID_INTERVAL {row_id}")

    active = [
        row for row in rows
        if (
            row[4] == "CONFIRMED"
            and minute(row[2]) < minute(row[3])
        )
    ]

    for first, second in combinations(active, 2):
        if first[1] == second[1] and overlaps(first, second):
            issues.append(f"CONFLICT {first[0]}/{second[0]}")

    return sorted(issues)

baseline = inspect(BOOKINGS)
for issue in baseline:
    print("BASE", issue)
print("BASE_COUNT", len(baseline))

print(
    "BOUNDARY_S01_S02",
    "OVERLAP" if overlaps(BOOKINGS[0], BOOKINGS[1])
    else "NO_OVERLAP",
)

print(
    "CANCELLED_S05",
    "NOT_OCCUPYING"
    if BOOKINGS[4][4] == "CANCELLED"
    else "OCCUPYING",
)

# Controlled status-change variant: S05 only.
variant = [
    (*row[:4], "CONFIRMED") if row[0] == "S05" else row
    for row in BOOKINGS
]
changed = inspect(variant)
for issue in changed:
    print("VARIANT", issue)
print("VARIANT_COUNT", len(changed))

# Incomplete-input negative control: omit S04 only.
incomplete = [row for row in BOOKINGS if row[0] != "S04"]
missing = inspect(incomplete)
for issue in missing:
    print("INCOMPLETE", issue)
print("INCOMPLETE_COUNT", len(missing))

assert baseline == ["CONFLICT S03/S04", "INVALID_INTERVAL S06"]
assert len(changed) == 3
assert len(missing) == 1

Compare the printed result and its limits with the BSL1 worked result in the final appendix. The six S-series inputs are a separate preparation fixture, never case evidence for R1–R8.

Week 1 review unit 2 — Do not turn an empty input into a clean schedule

Objective and observed behavior

Explain how to reject an incomplete or uninterpretable rehearsal frame while preserving the original booking-rule findings. This unit extends BSL1; it does not change its half-open interval convention, confirmed/cancelled status meanings or S01–S06 fixture.

In the original program, inspect([]) returns []. This is consistent with checking pairs in an empty sequence: there are no supplied conflicting pairs. It is not a demonstration of a healthy six-booking frame. Similarly, minute("9:00") returns 540 because the parser converts the two numeric pieces; it does not enforce a two-digit hour representation. The original baseline uses well-formed strings, so its existing results are not invalidated by these probes.

The proposed guard makes the rehearsal's additional contract explicit. The expected identifiers must be a nonempty frozen set; each row must contain five nonempty strings; clock fields must use exactly two ASCII digits, a colon and two ASCII digits, with valid hour/minute ranges; statuses must have the two defined meanings; identifiers must be unique and exactly match the declared frame.

These are local teaching conventions, not universal requirements for real booking APIs. An actual service may validly use JSON lists, other status models or a different timestamp representation. It needs its own documented interpretation. The Python regular-expression documentation explains full-string matching; it does not prescribe our time or booking contract.

Why the duration finding must survive

S06 has equal start and end times. Both fields are interpretable under the clock contract. The original invariant therefore still reports INVALID_INTERVAL S06; the guard does not quietly repair the end time, drop the row or reinterpret it as a cancellation. Input admission and business-rule findings remain separate.

The same distinction applies to a complete frame that contains a genuine modeled conflict. A good guard must admit the interpretable rows and let the original rule report the conflict. Rejecting every problematic input would prevent the learner from seeing the business condition the laboratory is designed to teach.

Reproducible BSL1 extension

Run the complete original BSL1 listing first in a fresh session. Predict five new lines before running the following extension. The result is conditional on the supplied expected frame; neither identifier equality nor strict syntax authenticates a source.

# Run after the complete BSL1 listing, in the same Python session.
import re

W1_BSL_EXPECTED = frozenset({"S01", "S02", "S03", "S04", "S05", "S06"})

def w1_inspect_scoped(rows, expected_ids=W1_BSL_EXPECTED):
    if type(expected_ids) is not frozenset or not expected_ids:
        raise ValueError("INVALID_EXPECTED_SCOPE")
    if any(type(item) is not str or not item.strip() for item in expected_ids):
        raise ValueError("INVALID_EXPECTED_SCOPE")
    if type(rows) not in (list, tuple) or not rows:
        raise ValueError("EMPTY_OR_INVALID_INPUT")
    ids = []
    for row in rows:
        if type(row) not in (list, tuple) or len(row) != 5:
            raise ValueError("INVALID_ROW_SHAPE")
        if any(type(item) is not str or not item.strip() for item in row):
            raise ValueError("INVALID_FIELD_TYPE")
        row_id, room, start, end, status = row
        ids.append(row_id)
        for text in (start, end):
            if re.fullmatch(r"[0-9]{2}:[0-9]{2}", text) is None:
                raise ValueError("CLOCK_FORMAT")
            minute(text)  # Reuse BSL1's hour/minute range check.
        if status not in {"CONFIRMED", "CANCELLED"}:
            raise ValueError("UNKNOWN_STATUS")
    if len(ids) != len(set(ids)):
        raise ValueError("DUPLICATE_ID")
    if frozenset(ids) != expected_ids:
        raise ValueError("COVERAGE_MISMATCH")
    return inspect(rows)  # Preserve BSL1's overlap/duration findings.

def w1_show_bsl(label, rows, expected_ids=W1_BSL_EXPECTED):
    try:
        issues = w1_inspect_scoped(rows, expected_ids)
    except ValueError as error:
        print(label, "INPUT_REJECTED", str(error))
    else:
        print(label, "EVALUATED", ";".join(issues) if issues else "NO_FINDINGS_IN_SCOPE")

w1_bad_clock = [
    (row[0], row[1], "9:00", row[3], row[4]) if row[0] == "S01" else row
    for row in BOOKINGS
]
w1_show_bsl("W1_BASE", BOOKINGS)
w1_show_bsl("W1_EMPTY", [])
w1_show_bsl("W1_MISSING_S04", [r for r in BOOKINGS if r[0] != "S04"])
w1_show_bsl("W1_BAD_CLOCK", w1_bad_clock)
w1_show_bsl("W1_NARROW_SCOPE", [BOOKINGS[0]], frozenset({"S01"}))

The last call deliberately declares a different one-object frame. It is not a repaired version of the six-object test. Keep those two reports separate. Also retain the original BSL1 status-change and omitted-row sensitivity demonstrations: they teach what the unguarded model sees, whereas this extension teaches whether a result answers a predeclared frame.

Supplementary practice W1-R2

Objective: diagnose empty, missing and malformed input without suppressing valid invariant findings. Inputs: BSL1's six original rows and the five calls above. Required artifact: the five-line output, a five-row explanation of admission versus invariant result, and one proposed source request for the missing-S04 case. Constraints: preserve S06 unchanged; do not modify the original BOOKINGS; do not redefine the six-object frame to obtain a green result. Explain whether checking identifiers proves authentic or complete real-world collection.

Assessment: one point each for the unchanged baseline findings, empty-input rejection, missing-row rejection, strict clock explanation, and correctly limited one-row result. Claims of source authentication or service repair must be corrected. Original EX002, EX005 and EX010 keep their two-row, four-row and two-sentence requirements; this supplementary artifact is not inserted into those required fields. Worked answer.

Review synthesis

“No findings in the supplied rows” is not the same claim as “the intended input was complete,” and neither is a universal service-safety finding.

Worked checkpoint

A successful edit call is not proof that the booking state meets the owner-approved rule. In the BSL1 fixture, first compare the final reservation state with the stated invariant; then test the controlled status-change variant separately. Neither result becomes an R-series incident fact.

Practice — Lesson 02

EX002 — First two questions

Objective: choose checks that could change the restriction decision. Inputs: R1–R6 and the service/authority tables. Output: two rows with a precise question, the fact that makes it relevant, the authorized custodian or person to ask, and how either answer changes the decision. One question must test the training explanation; the other must test who used the account or whether edits continue. Record requests rather than saying the interview or log review has already occurred. A score of 2 requires different discriminators and a named approval path for any new identity collection.

Behavior-baseline extension: In the training question, specify which owner-approved behavior for B17/B18 must be checked beyond R6's calendar entry. In the account question, separate a source discriminator from the still-open business-contract question. BSL1's S-series results are not evidence about B17/B18.

Worked answer: EX002 in the final appendix.

EX005 — Timeline

Objective: preserve event order without turning sequence into causation. Inputs: R1, R3, R4 and R5. Output: a four-row UTC table with record ID, source, time and observed event, followed by an ordering sentence and a separate unsupported-causality sentence. Keep the 09:00 case-open time outside the event table. A score of 2 orders the four events correctly and explains why precedence alone does not identify the human actor or prove why the patron's view changed.

Extension: Add a separate checkpoint note case opened 09:00; decision 09:05; available R1–R8. Explain why the case-open and decision times must not be inserted into the four-row source-event chronology as if they were source events.

For full credit: A 2-point answer preserves chronology while rejecting human attribution and unsupported causality.

Worked answer: EX005 in the final appendix.

EX010 — Communication draft

Objective: communicate useful action without premature attribution. Inputs: R1–R8 and the 09:00 intake state, before the 09:05 decision. Output: exactly two sentences for an internal service-owner audience: the first states observed service signals and uncertainty; the second names a proposed next check, its owner and the expected 09:05 decision checkpoint. Do not say preservation, an interview or a restriction has already been approved or performed. A score of 2 gives a source pointer and an unambiguous distinction between planned and completed work.

Behavior-baseline extension: Keep exactly two sentences at the 09:00 intake checkpoint. Distinguish the R3/R4 edit records and R5 patron report from a verified incorrect business state; name a proposed service-owner check of expected behavior before the 09:05 decision.

Worked answer: EX010 in the final appendix.

Lesson 03 — Service paths, dependencies and degraded modes

Week 1, 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.

1.2b Essential service paths and degraded modes

A running component is not a delivered business service

A library website may respond while the underlying booking system cannot display current rooms or accept a reservation. A backup monitor may report a completed job while no one has shown that the resulting copy can restore a correct schedule. A help desk may still take a patron's request while the computer-based reservation cannot be accepted. All three situations illustrate the same preparedness problem: the organization can truthfully say that some technology remains operational without establishing that the user's promised outcome is available.

The existing Chapter 01 begins correctly with a service map and a D1 evidence-readiness contract. A service map tells the responder which components and owners matter. D1 asks whether useful observations could be obtained under authority, including source semantics and missing evidence. A third question is needed: which exact user-facing functions would a component fault affect? Answering it requires a function-specific dependency model rather than treating every component as either globally healthy or globally fatal.

A service function is a specific operation with a defined useful result. A technical dependency is something required to carry out that operation in the stated architecture and mode. A degraded mode is a deliberately narrower operating state in which some activities continue but other service commitments cannot honestly be made.

These distinctions are consistent with the emphasis on service dependencies and business function recovery in NIST SP 800-184, Guide for Cybersecurity Event Recovery and with risk-aware response preparation in NIST SP 800-61 Revision 3. Those NIST publications do not specify Harbor Library's internal routes; PATH1 is original classroom reasoning material.

Begin with the promise made to a patron

Imagine five distinguishable functions for a hypothetical reservation service: an informational page responding, a current list of rooms being displayed, an authorized staff member editing a booking, a front-desk employee recording a pending request, and a new backup job obtaining its source data.

The results are not interchangeable. A successful informational page response says little about reservation accuracy. An accepted staff edit is a business-state change, potentially requiring authorization and durable storage. A manual request receipt is not acceptance of a reservation. A backup job's access to a database is not a tested restore or an accepted return to service.

A weak readiness statement says, "the app is available." A more useful statement says, "the authorized staff-edit function produced the expected change to the intended booking and a reviewer checked the resulting authoritative state in a controlled test." The second statement has a testable outcome and a declared scope.

At rapid-course depth, learners should identify the unit of success before selecting a test. Is the question about reaching a page, viewing a current room, placing a reservation, collecting a pending request or producing a backup object? Each unit needs a different answer and may have different technical dependencies.

This framing also improves incident communication. The service owner may legitimately approve a limited request-intake workaround, but staff must not announce that rooms are confirmed while writes are unavailable. An honest degraded-service notice should explain what the user can do, what remains pending and what must occur before confirmation is possible.

Express path assumptions as a small dependency table

The PATH1 teaching model uses components named web, identity, database, helpdesk and backup. These categories resemble the service map, but their specific connections are invented. The canonical R1–R8 records do not confirm this topology.

Lesson table; scroll horizontally to read all columns →

A component in a path is required under this model. If a required component is unavailable, the script predicts the function is impaired. If every required component is marked available, it predicts only structural possibility, not verified correctness. The model does not implement authentication, data persistence, cache validity, backup integrity, patron notification or performance.

These limitations are not weaknesses to conceal. They define which engineering question the model answers. A small, explicit model can help identify the next owner or test, provided no one promotes its predictions into real observations.

By contrast, D1's source contract asks whether an application audit or identity record could prove what actually happened. BSL1's business-rule exercise checks overlaps and cancellation semantics using separate invented booking records. PATH1 does neither. It asks which functions could lose their modeled prerequisites under component loss.

A single component failure may impair several different functions

Consider the independent hypothetical case where the PATH1 database becomes unavailable. Because room_view, staff_edit and new_backup_job all list it as required, the model predicts those three functions are impaired. The informational page and manual help-desk intake do not list it, so they remain structurally possible in this simplified design.

That prediction is not equivalent to "the website is healthy." A resident might reach a page but fail to view a trustworthy room list. It is also not equivalent to "the whole library cannot help anyone." Under the fictional fallback assumption, the help desk can still receive an unconfirmed request.

An identity-service failure has another shape. It impairs the modeled staff-edit path but does not necessarily impair room viewing. This does not establish that Harbor Library actually permits unauthenticated read access; it reflects only the independent fixture.

A help-desk failure can remove the manual fallback while website-mediated paths remain structurally possible. During ordinary operation this might be inconvenient; during a wider outage it could remove the only permitted path for receiving new requests. Thus the business importance of a dependency depends on the operating context.

The correct incident question is therefore not simply "which component is red?" It is which useful function is affected, what other path remains, and what legitimate promise can still be made? Component counts cannot substitute for that analysis.

Single points of failure must name their affected outcome

Calling a component a "single point of failure" is incomplete without naming the function it can prevent. In PATH1, failure of web alone prevents the informational page, room view and staff-edit route. It does not, under the stated fixture, prevent help-desk request intake or a new backup job.

Likewise, the database is a single required element for the modeled room view, but not for the informational page. A real application may have additional dependencies or a working alternate route; the PATH1 table provides no evidence about them.

For a function with all-required dependencies, failure of any listed component is sufficient to impair that particular modeled path. A real resilient design might instead have alternatives—such as two equivalent service instances or a controlled cached read. Such alternatives must be explicitly documented and tested before they are used in operational decisions.

This beginner model deliberately avoids probability estimates. A list of components does not provide failure rates, correlations, repair times or evidence that alternate capacity is usable. Assigning an invented likelihood of downtime would add precision without support.

The preparedness value of this reasoning is asking a service owner to identify what is truly essential and which alternate route can safely meet a narrower requirement. It does not authorize changing a production configuration.

Available, degraded, unavailable and unknown are different conclusions

A route can be modeled available, modeled impaired, observed to work in a bounded test, or not yet tested. These statements should not be collapsed into a single green/red label.

For PATH1, the supplied Python fixture uses Boolean component availability and predicts structural status. Real components can fail partially: a database may answer reads while rejecting writes; an identity service may validate old sessions but not new ones; a cache may return stale content. In those circumstances a simple Boolean may hide important uncertainty.

If an analyst cannot determine a component's actual state, it would be improper to enter True merely so the model returns a green result. Record the condition as unknown and ask what observation could resolve it. The classroom script omits a third state for simplicity; the learner must report that as a modeling limitation.

A successful response from a web endpoint also does not prove that a booking change was authorized and durably committed. A help-desk receipt does not prove a room assignment exists. These are examples of overclaiming from partial success.

An accurate report might say, "under the selected model, the informational page path remains structurally possible, while the booking write path is predicted unavailable." It should not claim that real patrons can safely use the service without a corresponding test and owner acceptance.

Design a degraded mode with explicit boundaries

A degraded mode is not simply "whatever still works." It should be defined in advance by the service owner, with conditions for activation, an approved workflow, a duration or review trigger, a message that accurately describes service limits, and a path back to normal operations.

For a hypothetical request-only help-desk mode, the owner would need to answer:

1. May staff receive requests while the authoritative reservation service is unavailable?
2. Which minimum details can be collected safely and for what purpose?
3. Does the request remain pending until a later authorized check?
4. Who maintains receipt order and prevents duplicates or conflicting instructions?
5. Who communicates the distinction between receipt and acceptance to patrons?
6. What is the escalation route if the desk cannot keep up or the request is urgent?
7. Who authorizes eventual reconciliation and confirms the resulting business state?
8. What observable result ends the degraded mode?

This is a proposed business contract, not a claim that the canonical Harbor Library help desk followed such a procedure. The later Module 3 MQ3 laboratory teaches detailed request reconciliation, but PATH1 asks an earlier, different question: Would that kind of fallback function remain technically possible under a specified component fault?

Manual intake may be unavailable by policy even when the help desk is working. Staff may lack capacity, approved paper procedures or privacy safeguards. A model's technical possibility never overrides the service owner's operating constraints.

A safe degraded-mode statement says, "the request may be recorded for review." A dangerous statement says, "the room is booked" when the accepted reservation has not been established.

Readiness needs a verification plan for each function

Before accepting the function table, a service owner and technical custodian should identify the test that would challenge it. A useful test plan includes:

• The function and promised outcome.
• The proposed required components.
• The specific isolated fault or unavailable component.
• The predicted impairment or alternative behavior.
• The positive technical observation to look for.
• A negative or business-safety check.
• The responsible owner and permitted environment.
• A source and timestamp for the actual result.
• The limit of the conclusion and the required review.

For the modeled room view, a technical response alone might be insufficient if it returns stale or unauthorized data. For staff editing, a successful request does not prove the intended authoritative value was committed. For a backup job, creation does not prove the object is recoverable. For help-desk intake, a receipt does not prove the request was accepted.

This plan should be compared with existing D1 and BSL1 artifacts without copying their content. D1 specifies how a record could be obtained and interpreted; BSL1 defines some correct booking-state behavior; PATH1 specifies which path's prerequisites are being challenged. A real isolated test might draw on all three, but the conclusions remain separate.

If the expected negative test fails, record the failure rather than silently weakening the acceptance rule. If the input data are incomplete or the supposed fault was not actually induced, report an inconclusive test rather than a clean pass.

Contrast a tempting wrong conclusion with a defensible one

Incorrect hypothetical analysis:

"The database is down but the homepage responds, so the service is healthy. Staff can take requests at the desk, which means reservations are still confirmed. The backup component remains online, so the library can already restore everything."

This assumes that the informational page represents all booking functions; that a pending manual request is a completed reservation; and that a backup component or job outcome proves tested recovery. None of the claims follows from the PATH1 model, and no database outage appears in canonical R1–R8.

Correct bounded analysis:

"In the independent PATH1 model, database unavailability predicts impairment of the room-view, staff-edit and new-backup-job paths, while the informational page and help-desk request intake remain structurally possible. Manual intake does not accept reservations, and no recovery test is supplied. These are sensitivity predictions from declared assumptions, not Harbor Library incident observations. The service owner would need to approve any degraded operating promise, and a separate authorized check would be required to establish actual function and business correctness."

The improvement is not simply cautious language. It identifies the unit of service, the source of the claim and the missing acceptance evidence.

Compare fault scenarios without turning them into canonical events

A useful offline rehearsal changes one modeled condition at a time and records which functions change classification. The student should begin with the baseline, simulate a database failure, restore the baseline and simulate identity failure. The same process can be used for help-desk and web failures.

Without resetting the model, conclusions can become mixed: a lingering database-down condition may make an identity test appear to impair more functions than it really does. The code below avoids this by evaluating independent failure sets rather than mutating the shared route definitions.

Comparisons should be explained in business terms. If identity failure affects only the staff-edit path, that is different from database failure affecting viewing, editing and new-backup creation. If help-desk failure removes intake, the potential harm depends partly on whether users have another approved means of making requests.

A two-component failure is useful as a negative control. With both database and help desk unavailable under PATH1, the remaining informational page cannot provide accepted booking writes or receive pending requests. It would be misleading to label that state "partially operational reservation service" without specifying the limited information-only function.

The fixture provides no frequency, probability or severity score for these scenarios. Those require information from the service owner and measured operational evidence outside the classroom.

Relationship to incident decisions at 09:05

Return to the actual fictional Round A source set. R1 reports a desk-a sign-in, R3 and R4 report booking changes, R5 is a patron concern, R6 describes scheduled training, R7 reports a backup-job completion and R8 lacks sufficient destination detail. These records support questions about approval, service state and identity context. They do not establish any PATH1 component outage.

A student might reasonably propose that the service owner clarify what would happen if the database were unavailable, or whether a request-only fallback is approved. That is a readiness question, not a finding about the incident.

A PATH1 scenario must never be inserted as an additional R-series row or used to justify the 09:05 restriction decision. Likewise, the later B19/B20 events or Branch S/P results cannot be imported backward to resolve the original uncertainty.

A high-quality responder can maintain two ledgers: the canonical evidence ledger, limited to released case records, and a model/test ledger, containing declared assumptions and hypothetical outcomes. This separation permits technically useful planning without fictionalizing production observations.

Section synthesis: resilience is a bounded service promise

Resilience is not a guarantee that every component stays online. It is the ability to define important user outcomes, identify how component failure could affect them, prepare acceptable narrower modes, and test what those modes actually deliver.

A website may be reachable while current room viewing is impaired. A help desk may be able to receive a request without confirming a reservation. A backup job may be possible without demonstrating recovery. Recognizing these distinctions improves the quality of incident questions and makes subsequent service-owner decisions more defensible.

The PATH1 laboratory is purposely small. It trains one transferable habit: predict structural consequences, identify the business promise, and demand appropriate observation before declaring service impact or recovery.

PATH1 Offline Laboratory — Functional Dependencies and Degraded Service

Classification: Independent, entirely synthetic modeling exercise. Not R1–R24, not the BSL1 booking-state fixture, not the technical-level L6 architecture and not a recorded Harbor Library outage.

Environment: Python 3 standard library, in memory. No files, network calls, real credentials or service modifications.

Prediction task: Before running, predict which functions remain in each scenario and whether the result means modeled staff-edit availability, request intake only or no modeled staff-edit/intake route.

The summary mode classifies only the staff-edit and request-intake paths. Read the separate available list before saying whether room viewing or any other function remains possible.

Complete Python program

ROUTES = {
    "site_reachable": {"web"},
    "room_view": {"web", "database"},
    "staff_edit": {"web", "identity", "database"},
    "manual_intake": {"helpdesk"},
    "new_backup_job": {"database", "backup"},
}

CASES = [
    ("BASE", set()),
    ("DATABASE_DOWN", {"database"}),
    ("IDENTITY_DOWN", {"identity"}),
    ("HELPDESK_DOWN", {"helpdesk"}),
    ("WEB_DOWN", {"web"}),
    ("DATABASE_AND_HELPDESK_DOWN", {"database", "helpdesk"}),
]

def assess_failed(failed):
    available = sorted(
        name for name, needs in ROUTES.items()
        if needs.isdisjoint(failed)
    )
    impaired = sorted(set(ROUTES) - set(available))

    if "staff_edit" in available:
        mode = "STAFF_EDIT_PATH_MODELED"
    elif "manual_intake" in available:
        mode = "NO_STAFF_EDIT_INTAKE_MODELED"
    else:
        mode = "NO_EDIT_OR_INTAKE_PATH"

    return available, impaired, mode

for name, failed in CASES:
    available, impaired, mode = assess_failed(failed)
    print(
        f"{name}: available={','.join(available)} "
        f"impaired={','.join(impaired)} mode={mode}"
    )

assert assess_failed({"database"})[2] == "NO_STAFF_EDIT_INTAKE_MODELED"
assert "room_view" not in assess_failed({"database"})[0]

Predict the six output lines before running the program, then compare your result with the PATH1 worked result in the final appendix. Keep PATH1 separate from the R-series case evidence.

Week 1 review unit 3 — Reject unknown names; model unknown states

Objective and counterexample

Distinguish an invalid component identifier from a valid component with unknown state. Then explain why a known failed prerequisite can establish modeled impairment even when another prerequisite is unresolved.

The original PATH1 evaluates a set of failed components. If the supplied set is {"databsae"}, the misspelled name intersects none of the five route dependency sets. The original function consequently returns every modeled function as available. This is a reproducible input-boundary limitation, not a report that a database or real service was healthy.

An identifier guard should reject that spelling rather than guess that the writer intended database. Silent correction could conceal a wrong source, a schema change or a different component. Request an explicit corrected input and preserve the original one.

A different problem arises when database is spelled correctly but its state is not known. Rejecting its name would be wrong; entering False would invent an outage; entering True would invent availability. The extension uses None to represent this narrowly defined unknown condition, with every component explicitly present in the state dictionary.

Reason through three states

PATH1 defines each route as an all-required set. Under that model, a function is:

Lesson table; scroll horizontally to read all columns →

Consider staff editing, which requires web, identity and database. With web and identity true and database unknown, the route is unresolved. With web true, identity false and database unknown, the route is impaired regardless of how the database uncertainty is later resolved. The known failed prerequisite is sufficient within this model. That conclusion does not identify the cause of a real outage, quantify harm or establish that an alternate architecture is absent.

Manual intake depends only on helpdesk in PATH1. If helpdesk is true, that route can remain possible while staff editing is impaired. “Possible” still means a modeled route, not a confirmed room booking, an approved fallback procedure or observed delivery of service.

Reproducible PATH1 extension

Run the complete original PATH1 listing first in a fresh session. Predict the first four new lines manually. The final loop checks all 3^5 = 243 partial assignments across the five components. For each assignment, it enumerates every complete Boolean assignment consistent with the declared unknowns and compares each function's possible outcomes with the three-state classification.

This comparison is an independent calculation over a finite declared model. It does not verify real topology, measurements, permissions, alternate paths or service correctness. For real systems, the assumptions themselves require authorized observation and owner review.

# Run after the complete PATH1 listing, in the same Python session.
W1_COMPONENTS = frozenset().union(*ROUTES.values())

def w1_assess_failed(failed):
    if type(failed) not in (set, frozenset):
        raise ValueError("INVALID_FAILURE_SET")
    if not failed.issubset(W1_COMPONENTS):
        raise ValueError("UNKNOWN_COMPONENT")
    return assess_failed(failed)

def w1_assess_state(state):
    if type(state) is not dict or set(state) != set(W1_COMPONENTS):
        raise ValueError("COMPONENT_SET_MISMATCH")
    if any(value is not None and type(value) is not bool for value in state.values()):
        raise ValueError("INVALID_COMPONENT_STATE")
    result = {}
    for function, needs in sorted(ROUTES.items()):
        values = [state[component] for component in needs]
        if any(value is False for value in values):
            result[function] = "IMPAIRED"
        elif any(value is None for value in values):
            result[function] = "UNRESOLVED"
        else:
            result[function] = "POSSIBLE"
    return result

try:
    w1_assess_failed({"databsae"})
except ValueError as error:
    print("W1_TYPO", str(error))
w1_state = {component: True for component in W1_COMPONENTS}
w1_state["database"] = None
print("W1_UNKNOWN_DB", w1_assess_state(w1_state)["staff_edit"])
w1_state["identity"] = False
print("W1_UNKNOWN_DB_IDENTITY_DOWN", w1_assess_state(w1_state)["staff_edit"])
print("W1_MANUAL", w1_assess_state(w1_state)["manual_intake"])

# Independent finite check: compare each partial assignment with every
# complete Boolean assignment consistent with it. No real system is queried.
from itertools import product
w1_names = sorted(W1_COMPONENTS)
w1_checked = 0
for values in product((False, True, None), repeat=len(w1_names)):
    partial = dict(zip(w1_names, values))
    unknown = [name for name in w1_names if partial[name] is None]
    completions = []
    for fill in product((False, True), repeat=len(unknown)):
        complete = {**partial, **dict(zip(unknown, fill))}
        completions.append(complete)
    actual = w1_assess_state(partial)
    for function, needs in ROUTES.items():
        outcomes = {all(complete[name] is True for name in needs) for complete in completions}
        expected = ("POSSIBLE" if outcomes == {True} else
                    "IMPAIRED" if outcomes == {False} else "UNRESOLVED")
        if actual[function] != expected:
            raise AssertionError((partial, function, actual[function], expected))
    w1_checked += 1
print("W1_PARTIAL_STATES_CHECKED", w1_checked)

Supplementary practice W1-R3

Objective: justify a result under incomplete component knowledge. Inputs: the five PATH1 functions, their original dependencies and the extension above. Required artifact: the five-line transcript; a table for all five functions with database unknown and all other components true; a second table after identity alone becomes false; and a two-sentence service-owner message distinguishing modeled intake from confirmed booking acceptance. Constraints: do not turn unknown into false, repair the typo silently, or import any modeled failure into R1–R8.

Assessment: one point each for typo rejection, the first complete function table, the second complete table, the limited service-owner message, and explaining what the finite enumeration does not verify. The original EX003 still requires its two dependency cards; this table is separate supplementary practice. Worked answer.

Review synthesis

An invalid name is an input defect. An unknown state is an unresolved premise. A known failed prerequisite can settle a modeled route without settling every other uncertainty.

Worked checkpoint

If the booking application responds but the authoritative reservation state is unknown, availability is not business correctness. A manual intake path may preserve a limited user promise, but it cannot be called confirmed booking acceptance without owner-approved reconciliation.

Practice — Lesson 03

EX003 — Service dependency

Objective: connect an incident signal to service outcomes and evidence owners. Inputs: the section 1.2 service map and R1–R8. Output: a two-row dependency card with dependency, possible user harm, supplied pointer, missing discriminating evidence and custodian. Choose two dependencies; for each, explain what an authorized check would distinguish. Do not call a potential harm a confirmed outage. A score of 2 needs two different dependencies and a test that could separate a service-state problem from account misuse.

Extension: For each of the two chosen service dependencies, distinguish a possible downstream business harm from an actual observation. Name one negative test that could weaken the proposed explanation and identify who would be authorized to request it.

For full credit: A 2-point answer explicitly connects different technical sources to different decisions. The database's current booking values cannot be inferred directly from R3–R4's edit history.

PATH1 supplementary task (after the required artifact):

Additional requirement: After the existing two dependency cards, choose one PATH1 modeled function and identify a component fault that would impair it. State an authorized functional check and a separate business correctness check. Do not claim that the PATH1 fault occurred in canonical R1–R8.

Worked answer: EX003 in the final appendix.

EX008 — Evidence quality

Objective: limit claims to what three different source types actually say. Inputs: R6–R8. Output: a three-row evidence-limit table with ID and time, narrow supported conclusion, tempting unsupported conclusion, and a follow-up source or test. A score of 2 treats a scheduled activity as distinct from an approved booking change, a completed backup job as distinct from a proven restore, and a summary missing destination detail as distinct from a verified absence of transfer.

PATH1 supplementary task (after the required artifact):

Additional requirement: In the R7 backup-status row, explain why modeled new_backup_job availability would not verify usable restore, acceptable elapsed recovery or owner-approved booking correctness. Preserve the original R6 training and R8 network-summary source limitations.

Worked answer: EX008 in the final appendix.

EX011 — Escalation trigger

Objective: specify when the initial choice must be reopened. Inputs: the R1–R8 snapshot and section 1.9. Output: two hypothetical observation/response rows with source that would verify the signal, harm or uncertainty affected, decision owner and next action. One trigger should concern continued booking change; the other should concern breadth or service impact. A score of 2 states that neither observation is present at 09:05 and avoids an automatic production action without approval.

Behavior-baseline extension: For the hypothetical service-impact trigger, specify a future owner-approved booking-state comparison against the applicable policy version, with the service owner confirming rule and scope. Keep the other trigger about a separately verified new unexplained edit. Neither signal is present in R1–R8; a rule mismatch does not prove cyber compromise.

Worked answer: EX011 in the final appendix.

Lesson 04 — Authority, delegation and pre-incident rehearsal

Week 1, 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.

1.3 Roles and decision authority

A small organization may assign several roles to one person, but the decisions remain distinct:

Lesson table; scroll horizontally to read all columns →

The analyst should not shut down a service merely because a dashboard looks unusual. The service owner may not decide that logs are irrelevant because the service appears available. The incident lead brings the owners and evidence together, records the decision and revisits it as facts change.

A useful decision record contains a timestamp, the current situation, available options, the chosen action, the person who approved it, the evidence supporting it, expected effects and a review time. Record rejected options as well when they explain an important tradeoff. A terse record made during the incident is more reliable than a reconstructed story written weeks later.

Separate recommendation, approval, execution and verification

One person can perform more than one role in a small team, but four verbs should remain visible in the case record. The analyst recommends an action and cites observations. An accountable person approves its scope and tradeoff. An operator executes the bounded change. A reviewer verifies whether the change achieved its objective and records any harm. None of these verbs can be inferred safely from a job title alone. NIST SP 800-61 Rev. 3, sections 2.2–2.3 discusses distributed response roles and the need for documented authorities and procedures; the four-verb record below is OpenCyber Academy's teaching device for making those authorities observable.

Lesson table; scroll horizontally to read all columns →

These assignments are fictional exercise rules. They are not a claim about any real organization's legal authority or an instruction to disconnect a production system. A useful approval says more than “go ahead”: it names the target, action, duration, expected disruption, evidence to preserve, rollback trigger and next review. If an urgent action is needed but the designated approver cannot be reached, the response lead follows the organization's approved escalation policy; the learner must not invent authority from silence.

Consider a recommendation to restrict desk-a after R1–R5. The analyst can state a plausible benefit: additional unauthorized edits might stop. The analyst must also state a plausible cost: front-desk staff might lose access during a busy period. Neither benefit nor cost is yet measured. A decision record that says “account compromised; disable immediately” hides both uncertainty and authority. A better provisional record is: “At 09:05 UTC, preserve the supplied records and seek the training owner's confirmation by 09:15; if an unexplained new booking edit appears, reconvene the incident lead, service owner and identity administrator for an approved restriction.” The time and threshold here belong to this synthetic case, not to a universal response policy.

1.3a Rehearsing authority before an incident

1.3a.1 From knowing a job title to proving a usable decision route

A response plan may correctly say that the service owner approves an interruption and the incident lead approves a bounded collection. That statement is necessary but not enough to know that a future decision can be executed lawfully and safely. What if the primary owner changed positions last month? What if the listed alternate can authorize a small room-booking pause but not an export of unrelated patron data? What if the approval route works during office hours but nobody has tested the designated contact channel? What if the delegation was revoked or its date passed?

An incident response team should discover such gaps before a real event forces a difficult choice. The preparation question is not "Does a person appear in a chart?" It is "Can a reviewer reconstruct an exact, currently valid path from a named request to the responsible decision maker and custodian, with explicit scope and a safe result when the path fails?"

Section 1.3 distinguishes recommendation, approval, execution and verification. AR1 asks students to rehearse whether those stages are reachable through current authority records. A successful pre-incident rehearsal demonstrates only that the simulated routing and verification rules were applied correctly for a declared version and time. It does not preapprove later actions or establish that a real person answered a real message.

NIST SP 800-61 Revision 3 places incident-response planning and coordination within Cybersecurity Framework 2.0 risk management. NIST SP 800-84 addresses the design, conduct and evaluation of IT plan tests and exercises. The versioned authority-register and validation procedure developed here are original educational techniques for exploring those documented concerns, not forms prescribed by NIST.

1.3a.2 A role name is not proof that a particular person holds authority

A service map may name "service owner," "identity administrator," "application custodian" and "incident lead." Each label describes responsibility, but the label alone does not establish which person currently fills the role, which specific actions they can approve, or whether a listed alternate is allowed to sign on the primary's behalf.

A role is a category of responsibility. An appointment associates that role with a verified organizational identity for a declared time. A delegation gives a defined subset of authority to another person or role under explicit terms. A custodian manages an object or source and may carry out an authorized request but does not automatically own the business risk decision. A requester can explain why evidence is needed; being the requester is not the same as granting the request.

Before an incident, a reviewer should be able to locate the actual authoritative governance record for each appointment and delegation, together with its issuer, approval status, version and validity period. In a real organization, that record may depend on employment status, identity-management groups, formal delegations or other governed systems. The OpenCyber Academy exercise does not assume any particular implementation.

A name typed into a spreadsheet is weaker evidence than a current, owner-reviewed appointment supported by the organization's authoritative process. A contact-list entry may remain useful after a person leaves a role, but it is no longer a valid decision source unless the governance system says otherwise. If the reviewer cannot establish the appointment, the correct outcome is to hold the action and escalate, not to treat familiarity with the person's name as proof of authority.

1.3a.3 Establish a versioned register with explicit acceptance questions

A useful authority readiness register needs more than columns for name and phone number. It must tell an independent reviewer whether the proposed decision route is valid for the operation under consideration. At minimum, it should identify:

Lesson table; scroll horizontally to read all columns →

The register itself also needs provenance. A file named latest-authority.xlsx is not adequate evidence of being latest. A change identifier, accountable issuer, recorded review and version transition should make it possible to determine whether a local copy is obsolete. The reader should know which system is authoritative and how to resolve a conflict between two copies.

A register can be a paper table for the introductory exercise. The skill being taught is validating an explicit set of claims, not choosing a particular database or ticketing vendor. Its fields are fictional instructional design choices; no NIST source is presented as requiring this exact schema.

1.3a.4 Scope belongs to the delegation, not merely to the original request

Suppose the service owner can authorize a temporary pause of one staff-booking write route. An alternate may be delegated authority for that specific pause, for a short period. That delegation does not automatically allow the alternate to approve a production database restore, disable every account, retrieve patron newsletter records or extend the pause indefinitely.

The request must therefore be compared with the allowed operation and object scope in the register. The same named alternate might have different authority for evidence collection and for a disruptive service control. A delegate approved for one operation should be rejected for another unless a separate valid record covers it.

The AR1 fixture uses two deliberately narrow activities. First, a request to review a synthetic training-audit selection containing only TR-01 or TR-02 requires the fictional incident lead's decision and a designated audit custodian. Second, a request to prepare a staff-write pause requires both fictional incident-lead and service-owner decision roles; a documented alternate may fill the service-owner role only for that narrow class of pause.

This is a rehearsal of route validity, not the execution of either action. The output REHEARSAL_PATH_VALID_NOT_EXECUTED never means "audit collected" or "write pause applied." In a real incident, the team would still need a current business decision, collection or change authorization, operator receipt, technical verification and applicable privacy safeguards.

Scope checking should fail closed. If the request includes an unrelated object, the checker should not silently ignore that object and approve the rest as if the original request were unchanged. It should return a hold condition and require an explicitly corrected request.

1.3a.5 Validity periods and expiry are operational safety controls

An alternate's authority may be valid only for a specified interval. A reviewer needs to know both the effective start and the last valid instant, and should use a consistent time basis. In the AR1 teaching model, the delegation is effective from 13:00 to before 14:30 UTC on the fictional rehearsal date. A check at 14:15 can satisfy the time condition; a check at 14:31 cannot.

The strict rule matters: a previously valid delegation is not indefinitely valid. The fact that a person approved something yesterday does not grant them the same scope today. A register also can expire as a whole. A delegate cannot be treated as current under an edition that the governance process no longer accepts merely because the individual delegation date looks recent.

The exercise should distinguish expiry from revocation. Expiry means the delegated validity interval has elapsed. Revocation means a governed decision withdrew the delegation before its nominal end. Either should block reliance on the alternate for the affected operation.

If a timestamp is missing or cannot be compared, do not select the value that makes the test pass. The appropriate state is unverified time or authority, subject to review. The AR1 script assumes UTC-aware timestamps and rejects two explicit expired cases; it is not a substitute for authenticating clocks in real organizational records.

An approaching expiry can also be a readiness maintenance trigger. The team should review critical delegations before their deadlines, identify the next approved owner and rehearse the updated route. This prevents a contact list from becoming a silent single point of failure.

1.3a.6 The owner, approver and custodian can be different people

A request might be valid in business purpose but routed to the wrong custodian. For example, a service owner may approve a limited interruption while an application operator is the only role permitted to apply it. An incident lead may approve a narrow evidence request while the application custodian retrieves records. A collector may not be authorized to approve expanded collection merely because they possess technical access.

The register should model both who may decide and who may carry out the approved task, as separate checks. A valid approver with an invalid executor is not a valid execution route. Conversely, a valid executor with no valid approval must not carry out the action.

In AR1, the imaginary training-audit request names an audit custodian; the staff-write-pause request names an application operator. Swapping them produces a wrong-custodian result even when the requested scope and approver fields are otherwise correct.

This is not meant to impose an organization-wide requirement that every small-team role be held by a distinct human. The book already explains that small organizations may combine roles. The relevant requirement is that the logical decisions and evidence for each stage remain distinguishable. A single person holding multiple documented roles must still exercise each role within its applicable authority.

When the same individual would propose, approve and execute a high-impact change, the organization may require additional independent review according to its actual governance. AR1 does not create such a requirement or grant exceptions. It teaches learners to record the unresolved policy question rather than invent a separation-of-duties rule.

1.3a.7 Use a registered confirmation route rather than an unverified reply

Knowing the correct role is not enough if the request arrives through an untrusted or unregistered channel. A message from an account displaying a familiar name may not authenticate the person or their current role. A successful email delivery indicator does not establish decision authority.

An authority-readiness rehearsal should specify how the requester can verify a response through a route independently obtained from the approved register. A common concept is a callback or trusted organizational confirmation channel. The concrete method in a real deployment depends on the organization's identity controls, communications policy and threat model.

The AR1 script represents this complex requirement through the literal field registered-callback and a Boolean confirmation flag. These are toy assertions supplied by the exercise. They are not identity proof, a secret challenge, a cryptographic signature, a real phone call or consent.

The pre-incident question is: does the plan name a tested route that would let a reviewer distinguish a valid approver from an impersonator or an obsolete contact? A process that says "send an email to the owner" but has no procedure for verifying a surprising or high-impact instruction remains incomplete.

A negative rehearsal should deliberately supply an unregistered messaging channel and confirm that the proposed action is held. Another should withhold confirmation even when the name and route match. In neither case may the team interpret silence as approval.

This concept differs from the Module 4 DEL4 laboratory, which tests message delivery, version acknowledgement and read-back during simulated incident coordination. AR1 tests pre-incident trust in the authority path itself, before any incident action is selected.

1.3a.8 An approval receipt must identify the bounded decision

A fictional reviewer may receive a response saying "approved." That word alone is insufficient if it does not identify the request, target and scope, the respondent's role, the applicable register version and whether the approval remains current. An approval can be genuine for one task and irrelevant to another.

A useful planned receipt identifies the request ID, decision, operation, objects, approving role and identity, confirmation route, time, restrictions, expiry or review condition and the governing register version. The actual organization may use an established ticket or change process; this chapter does not prescribe a new production system.

AR1 uses a small SIM-RECEIPT placeholder to represent the presence of a fictional approval receipt. If the placeholder is absent, the toy validator returns HOLD_APPROVAL_MISSING. The presence of that placeholder does not authenticate the approver or authorize a real action; it merely lets the learner practice checking that a distinct receipt is part of the planned route.

This is an important epistemic limit. Software can check that fields exist and that values fit a rule. It cannot automatically establish that a real person consciously authorized a service disruption unless the surrounding organizational identity and decision processes supply that evidence.

During a rehearsal, explicitly label the result valid simulated path, not executed. This avoids the failure mode in which a "successful drill" is copied into an actual incident ticket and mistaken for a real approval.

1.3a.9 Two complete contrasting examples: a valid delegation and an unsafe substitute

Correct example — limited, current, confirmed route in a pre-incident rehearsal.

On the invented rehearsal date 2026-09-15 at 14:15 UTC, the register version is AR-3 and is within its stated validity interval. A practice request concerns only the fictional staff-write-route operation pause_staff_writes. The simulated incident lead lead-sim has a separate decision receipt. The named service owner owner-sim has issued a documented, unrevoked delegation allowing alternate-sim to fill the service-owner approval role for this operation and object only, effective from 13:00 until before 14:30 UTC. The designated executing role is app-operator-sim.

Both fictional approvals have scoped training receipts and confirmations through the register's stated registered-callback route. The validator returns REHEARSAL_PATH_VALID_NOT_EXECUTED. The correct interpretation is: the specified routing conditions passed in the isolated exercise. No production pause was approved, performed or verified; no real person's identity was authenticated by this script.

A packet suitable for a two-person pre-incident review would preserve the register version, delegate scope and expiry, simulated approval fields, expected operator, check time, stop conditions and the result. The receiving reviewer could reproduce the decision and identify which evidence a real implementation would need.

Incorrect example — a plausible but expired and unverified substitute.

At 14:31 UTC in a different artificial run, the same delegate's permitted interval has ended. Suppose someone copies the old owner's name from a contact list, adds a request affecting unrelated booking or newsletter objects, and sends it through an unregistered chat account saying that the matter is urgent. The request is not valid merely because the alternate previously held a relevant delegation or because the channel is available.

The first applicable rejection may be delegation expired or scope exceeded, depending on what the validator checks first. A real reviewer should record all discovered defects in the case's correction work, not interpret one program output as approval of everything it did not mention. The team must not fabricate a new delegation or allow the custodian to act based on that request.

The correct response is to hold collection or service change, identify the accountable governance/incident-lead escalation route, obtain a current register or designated approver through authorized channels, and record the unresolved decision. Escalation is an attempt to obtain authority, not an alternative form of authority.

These two examples are not events in the R1–R8 incident and must not be inserted into its 09:05 timeline.

1.3a.10 A safe escalation path does not grant permission

An emergency contact path may be necessary when the ordinary approver or alternate cannot be validated. But the word "escalate" is often misused to mean "find anyone senior enough to say yes." That approach undermines the reason for recording delegations and bounded authority.

A valid escalation procedure specifies who receives the blocked decision, which information may be disclosed, which role verifies the current appointment, how to obtain or clarify authorization, and what the technical operator must not do while the decision is unresolved.

For a collection request whose approval is missing, the analyst may continue assessing already supplied and authorized records under the permitted scope. That does not authorize access to a new system. For a potentially disruptive change with no verified service-owner route, the coordinator may document risks and request a valid decision; it does not authorize execution based on urgency alone.

AR1 includes SAFE_ESCALATION. The output is ESCALATE_HOLD_DELEGATION_EXPIRED: an escalation is requested while the original action remains held. This is deliberately different from REHEARSAL_PATH_VALID_NOT_EXECUTED.

A stronger real-world program might have a separately documented emergency authorization mechanism. If so, its scope, prerequisites, accountable approver and verification would need to be tested as another explicitly versioned authority rule. AR1 neither assumes nor invents such a mechanism.

This differs from the Module 4 F1 replay, where an approver becomes unavailable during a fictional response. The current exercise instead tests whether the pre-incident register and fallback process are ready and current, well before any R-series incident starts.

1.3a.11 A register must be tested against negative controls

A contact list can appear correct in the easiest path but fail when a person leaves, a delegation expires or a request changes scope. A meaningful readiness test therefore needs both positive and negative controls.

The positive control asks whether the correct approvers, scope, version, custodian, receipts and confirmation flags produce a limited readiness pass. Another positive control tests the specifically documented delegate within the valid time window. Those checks demonstrate only the logic of the simulated register.

Negative controls deliberately change one property at a time: replace the approver with the wrong person, broaden the requested objects, omit the approval receipt, use an outdated register version, change the custodian, use an unapproved confirmation channel, suppress confirmation, revoke a delegate, or advance the test time beyond expiration. Each should produce a distinct hold reason.

Why insist on this? If the checker accepts every test, it may not be enforcing any real constraint. If it rejects even valid requests, the organization could be unable to act efficiently when a real incident requires a decision. The quality of a readiness control depends on both kinds of behavior.

The lab outputs one primary rejection code for reproducibility. In an actual review, other defects may coexist. Reviewers should avoid declaring that all unreported fields were valid merely because the checker stopped at the first failure.

A negative control does not create an incident. Changing a training receipt's date to simulate expiry does not mean anyone's real delegation expired.

1.3a.12 Version drift and parallel copies

Authority records frequently change when employees rotate, services move between teams or emergency contacts are updated. A pre-incident rehearsal should include a version consistency check. The requester, approving role and custodian should have a reliable way to determine that they are using the same current register edition.

In AR1, version AR-3 is the synthetic current edition. A copied request still referring to AR-2 fails with HOLD_STALE_REGISTER. The program does not attempt to infer that the older edition may still be "close enough."

There is a separate whole-register validity interval. The example edition is accepted only from September 1 until before October 1, 2026. A check on October 2 returns HOLD_REGISTER_OUT_OF_DATE even when its content otherwise resembles a valid request.

These checks answer different questions. A version mismatch means the request is not relying on the designated current edition; register expiry means the edition's declared relying period has passed. An individual delegate can also expire while the register itself remains valid. A quality test distinguishes the three rather than calling all of them "contact error."

If two remote copies disagree, no spreadsheet title or locally cached value should win merely because it is convenient. The organization's governance owner needs a defined authoritative source and correction path. The response lead should hold any action whose authority cannot be resolved safely.

1.3a.13 Proof of identity and proof of authority are independent

A caller may genuinely be the person they claim to be, yet lack authority for a particular collection or disruption. Conversely, a directory entry may correctly list a role that belongs to someone else now. The exercise should therefore distinguish identity confidence from decision-scope confidence.

An approved callback method can help validate who is responding, assuming the real organization implements it properly. It does not establish that the respondent's delegation covers all objects. A versioned delegation can establish the documented scope but does not prove that a particular message was sent by the listed delegate. Both checks matter.

AR1's literal strings are not authentication. The field confirmed=True is provided by the instructor as an input premise; no challenge response, access token, signature or real telephone call is performed. The script cannot verify the employee roster, actual phone numbers or current organizational approvals.

An introductory student should be able to say: "The synthetic identity field matched the expected delegate and the synthetic route was declared confirmed; in a real environment I would need authenticated confirmation and an authoritative current delegation record before relying on either." That is more defensible than claiming the code has authenticated a human.

The reviewer must also avoid using the registry as permission to gather unrelated identity records. Authority to approve a booking-audit request is not an unlimited right to investigate everyone associated with the service.

1.3a.14 Rehearsal artifacts and closure evidence

A useful pre-incident rehearsal leaves behind more than a passing screenshot. The evidence package should identify the tested register version, simulated operation, affected object scope, check time, primary and alternate decision roles, designated custodian, confirmation-route requirement, fixture input, expected status and actual status.

It should separately record that the exercise used fictional identities and receipts, that no production action occurred and that the program did not authenticate any real source. An independent reviewer should be able to rerun the same script and understand why each negative case was held.

A remediation ticket might be opened if a rehearsal finds an outdated or missing alternate, ambiguous scope, no approved confirmation channel, overlapping delegation periods, or an owner without a defined callback path. A ticket is not closed by merely updating a contact page. Its closure test should repeat the relevant positive and negative cases under a reviewed register version and retain the result.

For example, a stale-delegation correction could require: a named register steward, a dated current record, a documented successor, an explicitly limited operation and expiry, a confirmed callback route and an independent test in which the old expired delegate is rejected while the current designated route passes. That is a measurable capability improvement.

The training evaluator should avoid assigning a percentage of "organizational authority correctness" based on the toy cases. A small synthetic test validates only its specified fixtures.

1.3a.15 How to use this preparation without contaminating Round A

The canonical Harbor Library incident begins with R1–R8, not the AR1 rehearsal. The R-series table reports a sign-in, dashboard access, booking changes, a patron report, scheduled training, backup-job completion and a network summary with missing destination detail. It does not contain AR1's roster, delegation issue dates, approval receipts, or confirmation routes.

A responder at 09:05 can use the general practice learned from AR1: confirm the proper owner, scope and approval before expanding collection or restricting service. But the responder cannot assert "the owner has already approved because AR1 passed," or include the rehearsal's invented personnel as actual Harbor Library actors.

The Chapter 01 case itself authorizes a bounded classroom analysis of the supplied synthetic records only. All further evidence collection and production-like control changes remain proposed unless the fictional case explicitly supplies a later approval and result. AR1 adds no such result.

In a future organization, pre-incident authority validation reduces a type of uncertainty; it does not eliminate the need for a contemporaneous decision at the moment of incident response. An earlier rehearsal's success may support confidence in the procedure while still requiring current appointment checks, case-specific scope, approval and execution receipts.

This is the key distinction from D1 (does the proposed evidence source exist and work?), BSL1 (does the service meet an approved business invariant?), PATH1 (which functions depend on which components?), and F1 (what happens when an approver is unavailable during an incident?). AR1 evaluates the governed permission path in preparation, before any of those actions is needed.

1.3a.16 Section synthesis

An authority map is not complete just because its role names are sensible. A team should be able to determine whether the current register version is valid, whether the correct person or documented delegate may approve an exact operation and object scope, whether the designated custodian is appropriate, whether the decision was confirmed through an approved route, and whether a missing or invalid condition stops the request.

A valid simulated path must not become a real approval. An invalid path must lead to a documented hold and safe escalation, not silent substitution of a senior-sounding person. The student who can make those distinctions is better prepared to coordinate under pressure without treating urgency as authorization.

The following Python fixture provides a reproducible set of positive and negative authority checks. It deliberately returns no executed production action in every scenario.

1.3b AR1 offline laboratory — versioned authority and delegation checks

Classification: Entirely fictional, pre-incident laboratory performed against an invented register. It is not an incident, real employee directory, organizational approval, authenticated callback, R-series evidence or the in-incident F1 replay.

Learning objective: Check requested operation and object scope, current register version, named approver or valid delegate, custodian, receipt, confirmation route and expiration before allowing even a simulated readiness-path pass. Demonstrate that escalation holds the unsafe request rather than authorizing it.

Environment: Python 3 standard library only. Everything runs in memory. No files, network, accounts, telephony, chat applications, credentials, privileged operations or personal data.

Fixture: The artificial authority register is AR-3, declared valid September 1 to before October 1, 2026. The separate delegate alternate-sim is permitted to fill the service-owner role only for the training pause_staff_writes operation on staff-write-route from 13:00 to before 14:30 UTC on September 15, unless revoked. The training-audit example concerns only TR-01 and TR-02. Literal identities are role aliases and do not correspond to real humans.

Reproducible program

from datetime import datetime
from copy import deepcopy

def utc(s):
    return datetime.fromisoformat(s.replace("Z", "+00:00"))

REGISTRY = {
    "version": "AR-3",
    "valid_from": utc("2026-09-01T00:00Z"),
    "valid_until": utc("2026-10-01T00:00Z"),
    "approver": {
        "incident_lead": "lead-sim",
        "service_owner": "owner-sim",
    },
    "delegation": {
        "delegate": "alternate-sim",
        "role": "service_owner",
        "operations": {"pause_staff_writes"},
        "scope": {"staff-write-route"},
        "valid_from": utc("2026-09-15T13:00Z"),
        "valid_until": utc("2026-09-15T14:30Z"),
        "revoked": False,
    },
    "custodians": {
        "training-audit": "audit-custodian-sim",
        "staff-write-route": "app-operator-sim",
    },
}

RULES = {
    "collect_training_audit": {
        "resource": "training-audit",
        "allowed": {"TR-01", "TR-02"},
        "roles": ("incident_lead",),
    },
    "pause_staff_writes": {
        "resource": "staff-write-route",
        "allowed": {"staff-write-route"},
        "roles": ("incident_lead", "service_owner"),
    },
}

def approval(principal, receipt="SIM-RECEIPT",
             route="registered-callback", confirmed=True):
    return {
        "principal": principal,
        "receipt": receipt,
        "route": route,
        "confirmed": confirmed,
    }

BASE = {
    "version": "AR-3",
    "as_of": utc("2026-09-15T14:15Z"),
    "operation": "collect_training_audit",
    "resource": "training-audit",
    "objects": {"TR-01"},
    "executor": "audit-custodian-sim",
    "approvals": {"incident_lead": approval("lead-sim")},
    "escalate": False,
}

PAUSE = {
    **deepcopy(BASE),
    "operation": "pause_staff_writes",
    "resource": "staff-write-route",
    "objects": {"staff-write-route"},
    "executor": "app-operator-sim",
    "approvals": {
        "incident_lead": approval("lead-sim"),
        "service_owner": approval("alternate-sim"),
    },
}

def evaluate(c, registry=REGISTRY):
    reason = None
    if c["version"] != registry["version"]:
        reason = "STALE_REGISTER"
    elif not (registry["valid_from"] <= c["as_of"]
              < registry["valid_until"]):
        reason = "REGISTER_OUT_OF_DATE"
    elif c["operation"] not in RULES:
        reason = "UNKNOWN_OPERATION"
    else:
        rule = RULES[c["operation"]]
        if not c["objects"]:
            reason = "EMPTY_SCOPE"
        elif (c["resource"] != rule["resource"]
                or not c["objects"].issubset(rule["allowed"])):
            reason = "SCOPE_EXCEEDED"
        elif c["executor"] != registry["custodians"][c["resource"]]:
            reason = "WRONG_CUSTODIAN"
        else:
            for role in rule["roles"]:
                item = c["approvals"].get(role)
                if item is None or not item.get("receipt"):
                    reason = "APPROVAL_MISSING"
                    break

                if item["principal"] != registry["approver"][role]:
                    delegate = registry["delegation"]
                    if (item["principal"] != delegate["delegate"]
                            or role != delegate["role"]
                            or c["operation"] not in delegate["operations"]
                            or not c["objects"].issubset(delegate["scope"])):
                        reason = "WRONG_APPROVER"
                        break
                    if delegate["revoked"]:
                        reason = "DELEGATION_REVOKED"
                        break
                    if not (delegate["valid_from"] <= c["as_of"]
                            < delegate["valid_until"]):
                        reason = "DELEGATION_EXPIRED"
                        break

                if item["route"] != "registered-callback":
                    reason = "UNAPPROVED_CHANNEL"
                    break
                if not item["confirmed"]:
                    reason = "CONFIRMATION_MISSING"
                    break

    if reason is None:
        return "REHEARSAL_PATH_VALID_NOT_EXECUTED"
    if c["escalate"]:
        return "ESCALATE_HOLD_" + reason
    return "HOLD_" + reason

CASES = [
    ("VALID_AUDIT", BASE),
    ("VALID_DELEGATED_PAUSE", PAUSE),
    ("EXPIRED_DELEGATE",
     {**PAUSE, "as_of": utc("2026-09-15T14:31Z")}),
    ("WRONG_PERSON",
     {**PAUSE, "approvals": {
         **PAUSE["approvals"],
         "service_owner": approval("visitor-sim")}}),
    ("EXCESS_SCOPE",
     {**BASE, "objects": {"TR-01", "newsletter-sim"}}),
    ("EMPTY_OBJECTS",
     {**BASE, "objects": set()}),
    ("APPROVAL_ABSENT",
     {**PAUSE, "approvals": {
         "incident_lead": approval("lead-sim")}}),
    ("STALE_VERSION", {**BASE, "version": "AR-2"}),
    ("WRONG_CUSTODIAN",
     {**BASE, "executor": "app-operator-sim"}),
    ("BAD_CHANNEL",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", route="unregistered-chat")}}),
    ("NO_CONFIRMATION",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", confirmed=False)}}),
    ("REVOKED_DELEGATE", PAUSE, {
        **REGISTRY,
        "delegation": {**REGISTRY["delegation"], "revoked": True},
    }),
    ("EXPIRED_REGISTER",
     {**BASE, "as_of": utc("2026-10-02T14:15Z")}),
    ("MISSING_RECEIPT",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", receipt="")}}),
    ("SAFE_ESCALATION",
     {**PAUSE,
      "as_of": utc("2026-09-15T14:31Z"),
      "escalate": True}),
]

for name, case, *overrides in CASES:
    registry = overrides[0] if overrides else REGISTRY
    print(name, evaluate(case, registry))

assert evaluate(BASE) == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
assert evaluate({**BASE, "objects": set()}) == "HOLD_EMPTY_SCOPE"
assert evaluate(CASES[11][1], CASES[11][2]) == "HOLD_DELEGATION_REVOKED"
assert (evaluate(CASES[-1][1])
        == "ESCALATE_HOLD_DELEGATION_EXPIRED")

Request-bound approval check (supplementary AR1 rehearsal)

The existing AR1 program correctly models the governed register's revocation flag, nonempty object scope, valid delegates, permitted custodian and approved confirmation channel. Its fifteen published results reproduce correctly. However, the core evaluate function tests whether a simulated approval item exists; it does not test whether the issuing decision record binds that item to the specific request identifier, operation, source and set of objects.

For example, the original BASE proposal requests TR-01 and includes a fictional generic receipt named SIM-RECEIPT. If the request is changed to another otherwise allowed object, TR-02, while the same receipt is reused, the original function returns REHEARSAL_PATH_VALID_NOT_EXECUTED. This is a reproducible limitation of the toy validator. It is not evidence that a real organization approved the second object.

The pre-incident governance lesson should not call that second request approved. The simulated approval record must be associated with a stable request identifier and its approved operation, resource, objects and role. The following supplementary check introduces a small, independent fictional issuer-side record that the requester cannot silently redefine inside the evaluated card. It does not provide real identity authentication, a digital signature or a valid production permission.

Supplementary AR1 Python 3 listing — run after the existing complete AR1 program

# These are invented issuer-side approval records for the classroom.
# The original AR1 program must have been executed first, so BASE,
# PAUSE, RULES, REGISTRY and evaluate are already defined.
SIMULATED_ISSUED_APPROVALS = {
    ("TRAIN-001", "incident_lead"): (
        "lead-sim", "SIM-RECEIPT",
        "collect_training_audit", "training-audit",
        frozenset({"TR-01"})
    ),
    ("PAUSE-001", "incident_lead"): (
        "lead-sim", "SIM-RECEIPT",
        "pause_staff_writes", "staff-write-route",
        frozenset({"staff-write-route"})
    ),
    ("PAUSE-001", "service_owner"): (
        "alternate-sim", "SIM-RECEIPT",
        "pause_staff_writes", "staff-write-route",
        frozenset({"staff-write-route"})
    ),
}

def evaluate_with_approval_binding(card):
    preliminary = evaluate(card)
    if preliminary != "REHEARSAL_PATH_VALID_NOT_EXECUTED":
        return preliminary

    for role in RULES[card["operation"]]["roles"]:
        item = card["approvals"][role]
        presented = (
            item["principal"], item["receipt"],
            card["operation"], card["resource"],
            frozenset(card["objects"])
        )
        issued = SIMULATED_ISSUED_APPROVALS.get(
            (card.get("request_id"), role)
        )
        if presented != issued:
            return "HOLD_RECEIPT_SCOPE_MISMATCH"
    return preliminary

valid_audit = {**BASE, "request_id": "TRAIN-001"}
valid_pause = {**PAUSE, "request_id": "PAUSE-001"}

reused_receipt = {
    **valid_audit, "objects": {"TR-02"}
}
wrong_reference = {
    **valid_audit, "request_id": "PAUSE-001"
}

for name, card in (
    ("REQUEST_SCOPED_TR01", valid_audit),
    ("REQUEST_SCOPED_PAUSE", valid_pause),
    ("REUSED_RECEIPT_TR02", reused_receipt),
    ("REUSED_REQUEST_ID", wrong_reference),
):
    print(name, evaluate_with_approval_binding(card))

assert (
    evaluate_with_approval_binding(valid_audit)
    == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
)
assert (
    evaluate_with_approval_binding(valid_pause)
    == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
)
assert (
    evaluate_with_approval_binding(reused_receipt)
    == "HOLD_RECEIPT_SCOPE_MISMATCH"
)
assert (
    evaluate_with_approval_binding(wrong_reference)
    == "HOLD_RECEIPT_SCOPE_MISMATCH"
)

Before running either program, predict which paths pass, which are held and whether escalation changes authority. Run the original listing first and compare its 15-line transcript with the AR1 worked result. Then run the supplementary listing in the same Python session and compare its four additional lines with the request-bound worked result. Explain why TR-02 passes the original routing check but fails the separate approval-binding check. In particular, the register, not the request, controls revocation; an empty object set is not a valid bounded request.

Week 1 review unit 4 — A string is not a confirmation

Objective and mechanism

Explain why a type check belongs before authority evaluation, and why it must not replace the authority evaluation itself.

The original AR1 reads if not item["confirmed"]. Under Python's documented truth-value rules, a nonempty string is truthy. Consequently the characters "false" do not behave like the Boolean False. Converting that string with bool() does not fix the meaning. Similarly, equality tests alone can blur Boolean and integer values; this teaching gate intentionally requires the exact Boolean type.

The defect is not that AR1's original confirmed=False test was wrong: that baseline still produces a hold. The additional counterexample uses a different type. In the reviewed source, the otherwise valid request with confirmed="false" passes both the original routing function and the later request-bound receipt check. The receipt check protects request association, not Boolean field interpretation. Two useful controls can therefore coexist with an untested input boundary.

This demonstration concerns the toy validator only. Its original confirmation flag was already a simulated premise, not a real callback or identity proof. The new type gate prevents one category of unintended interpretation; it cannot make the supplied flag an authenticated fact.

Preserve separate checks

Keep these questions in order: is the field interpretable under this contract; does the confirmation actually say true; does the current role and delegation cover the exact request; is the receipt bound to that request; and what real-world proof would be required before relying on any of those premises?

The proposed wrapper checks the shape of the approval container and exact Boolean types for confirmation, escalation and the current registry's revocation flag. It then calls the existing receipt-bound evaluator, retaining the original role, custodian, scope and time checks. This is deliberately not a complete schema validator: missing unrelated fields, malformed timestamps, arbitrary custom objects and authenticity remain outside its claimed coverage.

Do not map all unexpected text to false. A schema mismatch and an explicit negative confirmation are different findings. Do not automatically escalate malformed input because a string happens to be truthy. The safe outcome is a visible input hold and a request for a correctly typed, source-supported record.

Reproducible AR1 extension

Run the original AR1 program and its request-bound approval listing in a fresh session. The extension below does not edit BASE, PAUSE or their nested approvals; changed examples use independent copies. Predict eight new output lines. Pay particular attention to the exact 14:30 endpoint: the delegate's end is exclusive in the original contract.

# Run after AR1 AND its request-bound approval listing, in the same session.
# This adds a narrow type gate. It is not a full request-schema validator.
def w1_evaluate_typed(card):
    if type(card) is not dict or type(card.get("approvals")) is not dict:
        return "HOLD_INPUT_APPROVAL_SHAPE"
    if type(card.get("escalate")) is not bool:
        return "HOLD_INPUT_ESCALATE_TYPE"
    if type(REGISTRY["delegation"].get("revoked")) is not bool:
        return "HOLD_INPUT_REVOCATION_TYPE"
    for item in card["approvals"].values():
        if type(item) is not dict or type(item.get("confirmed")) is not bool:
            return "HOLD_INPUT_CONFIRMATION_TYPE"
    # Do not replace the role/scope/time/receipt checks with the type check.
    return evaluate_with_approval_binding(card)

w1_text_false = deepcopy(valid_audit)
w1_text_false["approvals"]["incident_lead"]["confirmed"] = "false"
w1_real_false = deepcopy(valid_audit)
w1_real_false["approvals"]["incident_lead"]["confirmed"] = False
print("W1_ORIGINAL_TEXT_FALSE", evaluate_with_approval_binding(w1_text_false))
print("W1_TYPED_TEXT_FALSE", w1_evaluate_typed(w1_text_false))
print("W1_TYPED_REAL_FALSE", w1_evaluate_typed(w1_real_false))
print("W1_TYPED_VALID", w1_evaluate_typed(valid_audit))
print("W1_TYPED_REUSED_RECEIPT", w1_evaluate_typed(reused_receipt))
for clock in ("13:00", "14:29", "14:30"):
    card = {**valid_pause, "as_of": utc("2026-09-15T" + clock + "Z")}
    print("W1_DELEGATE_" + clock, w1_evaluate_typed(card))

Supplementary practice W1-R4

Objective: distinguish input rejection, explicit nonconfirmation, request-scope rejection and delegation expiry. Inputs: the original AR1 rules, issued synthetic receipts, and the eight calls above. Required artifact: eight output lines; a four-row comparison of text false, Boolean false, valid true and reused receipt; plus a three-time delegation check for 13:00, 14:29 and 14:30. Explain why passing the new type gate is not a new approval.

Constraints: do not add real credentials or callback details; keep the issued receipt binding unchanged; use the original half-open delegate interval; preserve EX006's four responsibility rows and EX013's three-row gap register plus ticket. Assessment: one point each for the type distinction, explicit false hold, preserved receipt binding, exact expiry boundary and refusal to claim real authorization. Worked answer.

Review synthesis

A correctly typed Boolean is a usable field, not authenticated consent. A request-bound receipt and a type gate address different failure modes; neither replaces the other.

1.3c AR1 two-role readiness rehearsal

Objective: Before a simulated incident, verify that a second person can reconstruct the correct authority route from the current register and request packet, identify an expired or out-of-scope delegation, and choose a safe escalation without asking the packet author to invent a missing approval.

Roles: Register Steward / Packet Author and Independent Readiness Reviewer. A facilitator may observe but does not change the declared outcomes after seeing the reviewer's first answer.

Only permitted data: The artificial AR1 register, synthetic request and simulated receipts. No real employee details, company directories, telephones, credentials or services may be used.

Phase 1 — Author freezes the packet

The steward prepares AR1-packet-v1 and records:

1. Register ID, version, issuer role, effective interval and source status.
2. Training operation and permitted object set.
3. Primary approving role and named delegate, including issuer, operation scope, validity and revocation state.
4. Executing custodian/operator for the selected task.
5. Declared registered confirmation route and what a real confirmation would have to establish.
6. A simulated request ID, selected time, named requested operation and objects.
7. The expected safe output if the primary/alternate path cannot be verified.
8. The explicit statement "training review only; no current incident or production authorization."

The packet must be frozen before the reviewer begins. A missing field is kept missing; the author may not silently repair the record after learning the reviewer's objection.

Phase 2 — Reviewer reconstructs independently

Give the reviewer a clearly labelled valid scenario and an expired-delegate scenario, in that order. Without help from the packet author, the reviewer must identify: current register edition; correct approval roles; whether the named delegate is still valid for the exact request; correct custodian; approved confirmation route; whether all required simulated receipts are present; and the decision to hold or escalate if any condition fails.

The reviewer submits AR1-review-v1 with a small field-by-field table and one paragraph explaining the safe next step. A reviewer who says "the person is familiar, so act immediately" fails even if they correctly identify the contact.

The reviewer may consult the frozen register and request but may not ask the author whether a missing delegation "probably exists." If a field needed for authorization is absent, the correct response is unknown/hold with a request for an authoritative source.

Phase 3 — Preserve and adjudicate

Freeze the first response. Compare its decision with the source fields and code output. Record each discrepancy as a missing packet field, incorrect interpretation, or unresolved source/authority question. Do not erase the first submission when corrected evidence becomes available.

A follow-up AR1-packet-v2 can replace an expired delegation with a newly approved fictitious record, but that new version needs its own validity and confirmation tests. The second attempt is not proof that the first packet was adequate.

Acceptance and failure rules

A bounded pass requires the reviewer to identify the correct version, service/operation/scope, valid or invalid delegation, custodian, confirmation requirement and safe hold/escalation condition, without claiming execution. A critical fail occurs if the reviewer accepts an expired/revoked alternate, wrong person, unauthorized objects, missing decision receipt or unverified channel as permission to proceed. A correctable fail includes a missing version reference or unclear packet pointer that leaves the reviewer unable to determine authority; the current request remains held until corrected.

This is a preparedness rehearsal. Its performance does not say what happened in Harbor Library's R1–R8 incident. It measures a small versioned authority-check procedure, not the actual reliability of a real organization's emergency staffing.

Worked checkpoint

A named substitute in an old contact list cannot approve a new collection by title alone. Compare the current register version, object scope, expiry and registered confirmation path; if one fails, record the approval as pending and escalate through the designated route.

Practice — Lesson 04

EX006 — Role assignment

Objective: make recommendation, approval, execution and verification visible. Inputs: section 1.3's fictional roles, R7 and the classroom scope. Output: a four-row responsibility table for a possible booking outage, preservation of R1–R5, coordination of the next review and a contained restore test. Name the task owner, who approves it under the exercise rules and what would verify completion. Distinguish planning a restore test from having performed one. A score of 2 does not delegate an outage decision to the analyst or treat R7 as a tested restore.

PATH1 supplementary task (after the required artifact):

Additional requirement: Keep the original four-row role matrix. For the possible booking outage, distinguish an approved manual-request intake procedure from actual booking acceptance; name the service owner of the hypothetical degraded-mode decision, the help-desk custodian of receipts and the reviewer who would authorize reconciliation.

AR1 supplementary task (after the required artifact):

Additional check: Preserve the original four-row responsibility table. For the evidence-preservation and possible booking-outage rows, add a short reference to where a current owner/delegate appointment and custodian assignment would be checked before relying on it. State which approval remains pending if a substitute is expired, and what evidence would verify that an authorized operator actually performed a later action.

Full-credit criterion: The analyst, incident lead, service owner, custodian/operator and reviewer retain distinct logical responsibilities. A published directory listing is not enough to prove a valid delegate, and a positive rehearsal is not an executed collection or service change.

Worked answer: EX006 in the final appendix.

EX013 — Readiness gap

Objective: turn an exercise weakness into a measurable preparation change. Inputs: the service map, authority table, R7–R8 and the section 1.8 workshop. Output: a three-row gap register with missing capability, consequence and owner; then an improvement ticket with priority rationale, specific change, deadline and a pass/fail drill. A score of 2 names a test that would actually demonstrate the change, such as an owner-and-alternate decision drill or a contained restore rehearsal, rather than merely publishing a policy page.

Extension: The improvement ticket must include a falsifiable rehearsal with a pass and failure criterion. A fallback-authority drill can test an unavailable primary approver; alternative defensible tickets may test log retrieval or isolated recovery.

For full credit: Merely writing or publishing a policy does not satisfy an exercise that asks the learner to demonstrate a capability.

AR1 supplementary task (after the required artifact):

Additional check: Retain the three-row gap register plus one improvement ticket. Where the owner/alternate record is identified as a gap, require a versioned authority-register review and a negative readiness drill checking an expired delegate, wrong approver or excess scope. Define the accountable register steward, completion evidence and a fail/reopen rule. Do not duplicate the in-incident F1 replay.

Full-credit criterion: The ticket cannot close merely when a contact list is edited. It must demonstrate, under a frozen simulated version, that a valid path passes and invalid routes remain blocked, with the original inputs and independent result preserved.

Worked answer: EX013 in the final appendix.

Lesson 05 — Scope, case record and bounded first decision

Week 1, 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.

1.4 Scope, authorization and safety

This book's labs use synthetic records only. In real work, incident authority comes from organizational policy, a contract, employment duties or explicit written approval. The authorization should identify the systems, accounts, data, time window and actions allowed. Investigating a partner's system, collecting personal data, changing access rights or taking a production service offline may require additional approval.

Use the smallest action that answers the immediate question. Reading a prepared copy of a log is different from altering the live source. Exporting a dataset may widen the number of people with access. A screenshot can omit the timestamp or the query that produced it. When evidence could later matter for legal or disciplinary decisions, follow the organization's evidence-handling procedure and obtain specialist guidance. This introductory course teaches a record discipline; it does not certify a forensic process.

For the Harbor Library exercise, the permitted scope is a fictional table of eight records in this chapter. Learners may annotate, sort and reason about the table. They may not attempt to contact a real library, probe a real domain or test a real account.

Write scope as an executable boundary

“Investigate the alert” is too vague to guide safe practice. A useful classroom scope has an object (R1–R8), an allowed operation (read, annotate and compare), an excluded operation (connect to any real service or account), a time boundary (the session), an owner (the course facilitator or learner for the local copy), and a stop condition (the supplied records do not answer the question). A real response plan must also specify the organization and system authority, data handling and escalation route. The classroom scope is deliberately narrower.

Suppose a learner wants to investigate the device or sign-in origin associated with the reported desk-a authentication in R1. R1 identifies a successful account sign-in but does not supply a verified device, source-network context or human identity. The correct classroom step is to propose an authorization-bound question: “Identity administrator: if separately approved, identify the narrow sign-in source, interval, relevant device or session fields, their producer and timezone, and the method needed to preserve and verify those details.” The learner cannot perform that collection from the supplied R1–R8 table, and cannot access a real identity system on the strength of a classroom exercise. R8 is a different source: it is a network summary whose missing destination detail prevents a supported statement about data transfer. Device/session context for R1 and destination evidence missing from R8 must not be treated as the same field or the same custodial request.

Scope also affects the strength of a conclusion. If only R1–R8 are in scope, the sentence “No exfiltration occurred” is unsupported. R8 explicitly lacks destination detail, and the learner has no additional network records. A defensible sentence is “The supplied network summary does not permit a conclusion about data transfer.” This is not evasive writing: it tells the next reviewer exactly which kind of evidence is missing.

1.5 The first incident record

Open one record before investigating deeply. A practical minimum is:

Lesson table; scroll horizontally to read all columns →

Use UTC consistently in this exercise. If a source uses another timezone, retain its original timestamp and record the conversion, including the offset. Never silently reorder events whose clocks may differ. Give each evidence item an identifier so that a later statement can cite its basis.

Week 1 review unit 5 — Repair an unsupported observation without erasing evidence

Objective and source correction

Revise a claim that exceeds its source while preserving useful chronology, uncertainty and the exact original exercise format.

An earlier version of the example record in section 1.5 said that two booking edits followed a sign-in outside ordinary hours. R1 provides the 08:40 sign-in time; R3 and R4 provide the 08:43 and 08:44 edit times. R6 reports scheduled training from 08:30 to 09:00. None of those records defines ordinary operating hours or an approved sign-in schedule. The chronology is supported; the ordinary-hours comparison is not.

Do not replace the unsupported statement with its opposite. The packet also does not prove that the sign-in was ordinary or approved. A good correction removes the unsupported qualifier and keeps the question open.

Corrected section 1.5 observation, as shown above:

R1 records a staff-account sign-in at 08:40 UTC; R3 and R4 record booking changes at 08:43 and 08:44 UTC. Ordinary operating hours and authorization of these changes are not supplied.

The shared Round A preview now identifies Lessons 01–05 within Chapter 01. That correction does not move the records or change their release boundary. The hypothetical introductory example in Lesson 01 may still discuss what an unusual-hour alert could say; it must remain visibly hypothetical rather than a new fact about R1.

Trace support at the level of the sentence

A sentence can mix a valid observation with an unsupported qualifier. A reviewer should not classify the entire sentence as either perfectly supported or entirely useless. Split it into propositions: a sign-in was reported; two later edits were reported; the time was unusual; the edits were approved; a human identity was established. The first two have pointers in the packet; the others need evidence not supplied there.

This method also prevents a style edit from becoming a factual change. Replacing “recorded cancellation” with “unauthorized cancellation” is not merely stronger wording. It adds a decision about permission. Replacing “patron reported a problem” with “the service failed” adds independent verification. A useful correction log records the original wording, the unsupported addition, the narrow replacement and the evidence needed to revisit it.

The NIST SP 800-61 Rev. 3 publication situates incident response within cybersecurity risk management, and the CSF 2.0 publication describes organizational cybersecurity outcomes. Those sources provide context, not Harbor Library facts or a prescribed wording template. The seven-field correction below is original editorial reasoning over the supplied exercise.

Supplementary practice W1-R5

Objective: produce an evidence-bounded intake record. Inputs: R1–R8, the original section 1.5 HL-IR-001 and T-104 context, the 09:00 intake checkpoint, and EX007's requirements. Required artifact: exactly seven labeled fields in the original order: case ID/open time; service; reporter/source; observed signal with pointers; assessment/uncertainty; scope/authority; next question/owner/review. Add a separate one-sentence correction note explaining the removed ordinary-hours qualifier.

Constraints: do not claim a completed interview, collection, restriction, 09:05 decision, confirmed compromise or tested restore at the 09:00 intake. Keep the patron report distinct from verified booking-state harm. Assessment: one point each for correct time and source context, bounded observation, explicit unresolved authorization/state, permitted scope, and a proposed owner/review route. A seven-field form containing unsupported facts must still be corrected. This supplements EX007; it does not create EX051. Worked answer.

Review synthesis

A good correction narrows the claim to its evidence without erasing the evidence. The absence of an operating-hours rule establishes an unknown, not an ordinary or extraordinary event.

1.6 Worked example: a sign-in followed by booking changes

The synthetic records in section 1.7 provide the single source of case facts for this example. R1 records a desk-a sign-in at 08:40 UTC, R3 a change to B17 at 08:43, R4 a cancellation of B18 at 08:44, and R5 a patron report at 08:48. The team can say that the sign-in preceded both edits and the report. It cannot yet say that the account was stolen, that either edit caused every aspect of the report, or that data was exfiltrated. A safe next step is to preserve the relevant record identifiers, ask the service owner whether the edits match scheduled work, and request staff-account context through an authorized channel. Depending on organizational procedure and new evidence, the incident lead may then authorize additional collection or containment.

The alternative “disable the account immediately” has a possible benefit if the account is compromised, but it may stop front-desk work and obscure whether the staff member is actively making legitimate changes. The correct decision depends on impact, confidence, authority and available alternatives. Record that reasoning rather than presenting a guess as a universal rule.

1.7 A contained practice dataset

Use only these synthetic records for the exercises. They extend the worked example; they are not evidence of a real event.

Lesson table; scroll horizontally to read all columns →

R6 is a reason to check whether the edits were part of training; it is not proof that they were. R7 may support recovery planning but does not prove that a restore works. R8 cannot prove absence of data transfer. The lesson is to connect a claim to the evidence that actually supports it.

A three-hypothesis reading of the same records

Start with three explanations that are meaningfully different. H1: authorized training caused the booking changes. R6 makes this plausible because training was scheduled; R6 does not identify which bookings were meant to change. H2: someone used desk-a without authorization. R1–R4 are compatible with this, but they contain no proof about who controlled the session. H3: the patron view and authoritative booking state differ. R5 suggests a user-visible discrepancy, but R4 records a cancellation in the application audit, so H3 cannot by itself explain every observation. All three are hypotheses, and more than one contributing condition could be present.

The next check should be chosen for its ability to discriminate among these explanations at low cost and within scope. Asking the training owner whether B17 and B18 were specified in the training plan may strengthen or weaken H1. Comparing the authoritative booking state with the patron view may test H3. Reviewing a narrowly scoped, approved identity detail record could strengthen or weaken H2. The fact that a check is useful does not itself authorize collecting that record. If permission or data is unavailable, record the limit and revisit the decision with the case owner.

Lesson table; scroll horizontally to read all columns →

This is an example of evidence discipline, not a probabilistic verdict. With this small dataset, no defensible numerical probability of compromise can be calculated. A score invented from intuition would add apparent precision without adding evidence.

Let the service outcome set the evidence question

An alert title tells a responder what a detector noticed. It does not tell the responder which business result is at risk. For Harbor Library, the meaningful outcome is that residents can see and reserve the intended study rooms and that authorized staff can manage bookings without silently corrupting the schedule.

The existing service map lists a booking application, staff identity service, reservation database, nightly backup and help desk. Each has a different evidentiary purpose. An identity record can help investigate an account's authentication context; an application audit describes a reported operation; an authoritative booking-state check tests what is currently stored; a help-desk ticket records a reported user experience; a backup monitor describes a job. None should be substituted for another merely because its timestamp is convenient.

A beginner should write a decision-purpose sentence before requesting evidence:

"I need to determine whether B17 and B18 were authorized training changes before recommending an access restriction that could interrupt front-desk work."

That sentence fixes the relevant object, suspected harm, alternative explanation and pending decision. It also prevents an unjustified expansion to the unrelated newsletter contact list or all patron accounts.

A useful evidence question has two outcomes, not one. Ask: "What would I conclude if the requested record confirms the hypothesis, and what would I conclude if it contradicts the hypothesis?" If neither result would change the decision, the request may not be the best first use of limited time. This is a decision-value test, not a mathematical score.

For instance, the scheduled training in R6 makes an approved-operation explanation plausible, but R6 does not list B17 or B18 as approved tasks. A bounded request for the dated task list could strengthen or weaken that explanation. A broad network search, by contrast, cannot substitute for the missing task authorization merely because it might produce more data.

Keep a claim ledger with falsifiers

A record has a producer, a reported event, a timestamp, and a scope. The analyst adds an interpretation. Keeping those elements separate prevents a common logical shortcut: replacing "this source reports X" with "X happened exactly as I imagine it."

Use a claim ledger with five columns:

Lesson table; scroll horizontally to read all columns →

The "direct pointer" column does not turn a synthetic row into authenticated production evidence. It identifies the exact source within the exercise from which a statement was drawn.

A credible conclusion also needs a falsifier: an observation that would force the writer to change the current explanation. If the only acceptable evidence is evidence that confirms the favored theory, the analyst is not performing a meaningful test. An approved training plan excluding B18 would weaken the proposed training explanation; a plan including B18 would strengthen it for that edit but still would not establish who operated the session.

When the evidence is incomplete, "unknown" is an informative state. It identifies an unfinished dependency between question and proof. It must not be changed to "false" merely because a field or record is missing. R8 illustrates this directly: the absence of destination detail is not evidence that there was no transfer.

Keep the 09:05 information boundary explicit

Incident records use more than one time concept. An event timestamp describes what a producer reported. A case-open time describes when the response record began. A decision time describes when particular information and authority were used. Later discovery is not retroactive access to evidence.

In this exercise the source events R1–R8 have timestamps between 08:40 and 08:55 UTC, the case opens at 09:00, and the first decision checkpoint is 09:05. A good decision note states its available evidence set as explicitly as its timestamp:

case=HL-IR-001; checkpoint=09:05 UTC; available=R1–R8; later sources=not released

A peer reviewer can now ask whether every claimed fact was available to the decision maker. A later record with an earlier event time must remain excluded from this 09:05 reasoning. Otherwise the review suffers from hindsight bias: judging an earlier action as if the responder already knew facts received later.

Keep hypothetical injects in separate cards. If a trainer says "imagine another edit happens at 09:08," the learner may explain how the decision would change, but must not silently append the imagined event to R1–R8. Restoring the baseline after the counterfactual is part of the exercise.

1.8 Guided readiness workshop: prepare the first decision

This paper-and-pencil lab turns the eight fictional records into a reproducible case artifact. It requires no software, network connection, account, secret or real person. Work from the table in section 1.7 and the role and scope rules above. The outputs are a service card, an evidence ledger and a decision card. Keep the three artifacts together under the synthetic case ID HL-IR-001.

Step 1 — Define the service and authority. On the service card, name the room-booking outcome, the identity and database dependencies, the service owner to consult and the person who can approve record collection under the exercise rules. Mark the identity administrator as a potential custodian of additional sign-in details, not as a source already consulted. Record “synthetic R1–R8 only” as the current evidence boundary.

Step 2 — Build the evidence ledger. Copy the record IDs and UTC times for R1, R3, R4, R5, R6, R7 and R8. Add one column labelled “what this item directly records” and another labelled “what it does not prove.” For example, R7 directly reports a completed backup job; it does not establish the restored schedule or its recovery time. Do not merge the patron's report with the application audit into a single unqualified fact.

Step 3 — Set a decision checkpoint. At the fictional 09:05 UTC checkpoint, propose either (A) preserve the supplied records and verify the training explanation before changing access, or (B) request an approved temporary restriction of desk-a. For the chosen option, write its expected benefit, service cost, approving role, observable result and next review time. Also record the rejected option and the evidence that would cause reconsideration. Either choice can be defended if assumptions, urgency and authority are stated; R1–R8 alone do not force a universal answer.

Step 4 — Run a counterfactual. Imagine that at 09:08 UTC a newly supplied, verified application record shows another booking edited after the scheduled training window. This is a fictional inject, not part of R1–R8. State how it would change your assessment and which approval you would seek. Then remove the inject and return to the actual eight-record dataset. This separation prevents a hypothetical event from silently becoming case evidence.

Expected evidence: three labeled artifacts with the case ID, source IDs beside every factual statement, an explicit unconfirmed-cause status, a named approver for any disruptive action, and a next review time. A reviewer should be able to reconstruct the order of events and identify which statements were observations, inferences or proposals without asking the author.

Assessment rubric: award one point each for accurate event pointers and UTC ordering, clear separation of fact from hypothesis, explicit current authority and scope, a proportionate option comparison, and a review trigger with owner. A score of 5/5 shows the artifact is internally complete for this introductory exercise; it does not certify incident-response competence or prove the fictional case's cause. An omitted scope or approval item must be corrected even if the other four points are present. A worked example appears in the final answer section after EX013.

1.9 Build a decision gate from incomplete evidence

An initial response is a series of bounded decisions, not a search for certainty before anyone acts. At the 09:05 UTC checkpoint, the Harbor Library analyst has eight supplied records, a scheduled training interval and two booking changes. The records do not say who controlled desk-a, whether B17 and B18 were authorized training tasks, or whether a backup could actually restore a correct schedule. These unknowns call for discriminating questions, not invented answers. The decision gate below is an original teaching model for this fictional case. It illustrates the documented roles, authority and review practices discussed in NIST SP 800-61 Rev. 3; it is not a NIST-prescribed severity scale.

Lesson table; scroll horizontally to read all columns →

One defensible choice is to preserve the supplied records, ask the training owner about B17/B18 and reconvene at the review time. This avoids an immediate service interruption but accepts the possibility of a further edit. Another defensible choice, if the service owner describes a high impact of continued changes and the approving roles are available, is to seek a temporary account restriction with a defined end and a way for staff to continue essential work. The analyst's recommendation is not permission to execute either change. A reviewer should ask what fact would reverse the choice, who can authorize the reversal, and how quickly the resulting harm can be observed.

If the training owner confirms that B17 and B18 were on an approved task list, that weakens the hypothesis that those two edits were unauthorized. It does not prove the person controlling the session, nor does it settle any later B19 edit introduced in Module 2. If the task list excludes B18 and the owner confirms the list is complete, the training explanation for B18 weakens. If the list is unavailable, the answer is unknown, not “training was ruled out.” This distinction between a contradictory observation and a missing observation is fundamental to responsible incident decisions.

To make the gate reproducible, a second analyst should be able to read the same R1–R8 table, recover the same event order, locate the supporting record for each claim and see the approval path. If the second analyst cannot tell whether a sentence is a supplied fact, a hypothesis or a proposed action, rewrite it. Module 2 adds evidence preservation and discovery-time discipline to this same case; the later records must not be imported backward into the 09:05 decision.

Make the first decision a reproducible handoff

A handoff should allow a second learner to answer six questions without asking the original analyst for undocumented context:

• What service and decision are in scope?
• Which exact record identifiers support the current observations?
• Which hypotheses remain live, and what could disconfirm them?
• What has merely been proposed versus approved or executed?
• Who owns the next question or action?
• What deadline or observed trigger requires renewed review?

Compare two examples.

Insufficient: "Suspicious admin activity. Likely breach. Investigating."

Reviewable: "At the fictional 09:05 UTC checkpoint of HL-IR-001, R1 shows a desk-a sign-in, R3 and R4 report booking edits, and R5 reports a patron complaint. R6 documents scheduled training but not the authorized task list. The analyst has not identified a human actor or established compromise. The incident lead is asked to approve a bounded training-owner check and to review the service impact with the owner by 09:15 UTC; no real access restriction was performed."

The longer message is not better simply because it has more words. Each clause answers a question essential to the next decision. A handoff that confuses a proposed request with a completed collection can be more dangerous than a brief handoff that clearly marks the missing evidence.

NIST SP 800-61 Revision 3 addresses incident response as an organizational capability involving multiple roles and activities. The six-question handoff above is original OpenCyber Academy instructional material, not a mandated NIST form.

1.10 Offline laboratory: evidence-bound claim review

Goal: Classify claims against the exact Round A release and demonstrate how a missing source changes a supported teaching statement without changing the canonical incident.

Inputs: The eight fictional record identifiers, their existing timestamps and source types, plus six classroom claim cards. No new incident observations are introduced.

Environment: Python 3, standard library only. The fixture is in memory, requires no accounts, reads no files, and makes no network requests.

Before running: Predict which claims may accurately report the supplied record contents, which remain hypotheses, which exceed the source semantics, and which reference an unreleased record. In particular, do not treat "record content available" as "real event authenticated."

events = [
    ("R1", "08:40", "identity", "desk-a sign-in"),
    ("R2", "08:42", "application", "dashboard opened"),
    ("R3", "08:43", "application", "B17 moved"),
    ("R4", "08:44", "application", "B18 cancelled"),
    ("R5", "08:48", "helpdesk", "patron report"),
    ("R6", "08:50", "staff_calendar", "training scheduled"),
    ("R7", "08:52", "backup_monitor", "job completed"),
    ("R8", "08:55", "network_summary", "destination detail absent"),
]

assert len(events) == len({row[0] for row in events})
assert [row[1] for row in events] == sorted(row[1] for row in events)

available = {row[0] for row in events}

# Each card is an analytical claim, not another R-series event.
claims = [
    ("C01", {"R1"}, "record"),
    ("C02", {"R3", "R4", "R6"}, "hypothesis"),
    ("C03", {"R1", "R3"}, "actor"),
    ("C04", {"R7"}, "restore"),
    ("C05", {"R8"}, "no_transfer"),
    ("C06", {"R9"}, "record"),
]

def classify(refs, kind, released):
    if not refs <= released:
        return "NOT_IN_RELEASE"
    if kind == "record":
        return "RECORD_CONTENT_ONLY"
    if kind == "hypothesis":
        return "HYPOTHESIS_ONLY"
    return "NOT_ESTABLISHED"

for name, refs, kind in claims:
    print(name, classify(refs, kind, available))

# Negative test: make a temporary incomplete copy of Round A.
# This is not a deletion of canonical R6.
without_r6 = available - {"R6"}
print(
    "NEGATIVE_R6_MISSING",
    classify(claims[1][1], claims[1][2], without_r6),
)
print("EVENTS_IN_ROUND_A", len(events))

Exact expected output

C01 RECORD_CONTENT_ONLY
C02 HYPOTHESIS_ONLY
C03 NOT_ESTABLISHED
C04 NOT_ESTABLISHED
C05 NOT_ESTABLISHED
C06 NOT_IN_RELEASE
NEGATIVE_R6_MISSING NOT_IN_RELEASE
EVENTS_IN_ROUND_A 8

Worked interpretation

C01: R1 is available. The learner may report that the synthetic identity record states a successful desk-a sign-in. The output is not an independent authentication of the record or a human attribution.

C02: R3, R4 and R6 are all available. The training explanation can be formulated as a hypothesis, but the calendar entry does not authorize the specific edits. The code does not evaluate whether the hypothesis is true.

C03: Account and application records exist, but the actor's identity is not established. No field in the supplied release identifies the human operating the session.

C04: The reported backup-job completion cannot be converted into a proven restore result. No restore was executed in this fixture.

C05: R8 omits destination detail. A claim that no transfer occurred would exceed the source.

C06: The claim references R9, outside the Round A release. The code intentionally supplies no content for R9; the future record must not influence the 09:05 assessment.

Negative test: Removing R6 from a temporary set makes the training-hypothesis card lack one of its referenced sources. The result changes to NOT_IN_RELEASE for the temporary variant. No historical event or canonical R6 record has changed.

Validation, failure modes and limits

The first two assertions detect duplicate identifiers or unsorted printed timestamps in this literal fixture. They do not verify synchronization of independent real systems. The algorithm deliberately checks source availability and a simplified claim class; it does not perform semantic parsing of incident narratives, cryptographic integrity checks, authorization checks or independent source verification.

A learner who obtains the expected output has reproduced the stated classroom logic, not proven that Harbor Library experienced an incident. A learner who edits the Python input must preserve the original transcript and label the changed run as a variant.

Required artifact: Submit (a) the exact transcript, (b) a six-row claim ledger with evidence ID, supported wording and limitation, and (c) a two-sentence difference report for the negative test. Pass only when all original Round A facts remain unchanged, unsupported findings stay blocked and the hypothetical source removal is not represented as real evidence loss.

1.10a Readiness depends on authorized evidence, not a green inventory

Learning objective: For the early R1–R8 Harbor Library checkpoint, distinguish an operational capability, a decision owner, an authorized evidence route and a demonstrated rehearsal. Each item has a different source and a different possible failure. A junior responder should be able to identify the next safe request without inventing a completed collection.

A statement that the identity provider retains detailed session logs describes a possible source capability. The incident lead's request to examine a bounded interval describes intent. Permission from the proper identity/data owner is authorization. A source-linked export receipt and a repeatable check would be evidence of executed retrieval. None automatically creates the next. An available console is not permission to inspect unrelated patrons, and a ticket requesting an export is not the exported object.

Draw a four-edge dependency path: business question → authority → producer/selection → verified result. For each edge identify the decision that would fail if the edge were absent. At Round A, the relevant question is whether R3/R4 booking edits belong to a permitted training task; R6 makes training plausible but does not prove approval or identify the human. An analyst who has not established a source's clock and retention semantics cannot assert a particular safe collection deadline. A responder who has not verified the emergency delegation cannot assign authority to whichever colleague has access credentials.

Contrastive worked example A: A permitted training environment exposes a queryable booking-audit stream, but the alternate custodian has not been named. The technically available source is not operationally ready for out-of-hours authorized collection. Correct follow-up: ask the incident lead to locate and verify a valid delegated route; record unanswered approval and source-access questions. Wrong follow-up: run the query with somebody else's credentials because the incident seems urgent.

Contrastive worked example B: The owner and source-access route are approved, yet a harmless scheduled booking test produces no stable request identifier. Here permission is present but correlation coverage fails. The next action is a narrow producer/field test and an application-owner remediation question. It would be incorrect to describe all events as collected, or to identify a booking's operator using nearby timestamps alone. Neither example is a new R-series case fact.

NIST SP 800-61 Rev. 3 addresses preparation and incident response as linked risk-management activities. NIST SP 800-84 distinguishes discussion exercises from measured component tests. The following original learning classifier is only an in-memory classroom fixture, not a source/approval verifier.

R1X offline rehearsal — first unsupported readiness link

Run in isolated Python 3. Inputs are invented, reset between rows. No files, network calls, credentials or actual system changes are involved.

def ready(owner, alternate, source_route, receipt):
    if owner is None:
        return "HOLD_OWNER_UNNAMED"
    if alternate is None:
        return "ESCALATION_ROUTE_UNVERIFIED"
    if source_route is None:
        return "COLLECTION_ROUTE_UNVERIFIED"
    if receipt is None:
        return "REHEARSAL_NOT_EXECUTED"
    return "FIXTURE_DECLARED_REHEARSAL_ONLY"

cases = [
    ("C01_SCOPE", "service_owner", None, "source", None),
    ("OWNER_UNKNOWN", None, "approved_alternate", "source", None),
    ("NO_SOURCE", "service_owner", "approved_alternate", None, None),
    ("NO_TEST", "service_owner", "approved_alternate", "source", None),
    ("TOY_PASS", "service_owner", "approved_alternate", "source", "synthetic"),
]
for name, *fields in cases:
    print(name, ready(*fields))

Exact independently reproduced Python output:

C01_SCOPE ESCALATION_ROUTE_UNVERIFIED
OWNER_UNKNOWN HOLD_OWNER_UNNAMED
NO_SOURCE COLLECTION_ROUTE_UNVERIFIED
NO_TEST REHEARSAL_NOT_EXECUTED
TOY_PASS FIXTURE_DECLARED_REHEARSAL_ONLY

Adversarial test: Replace TOY_PASS's final string with None; the output becomes REHEARSAL_NOT_EXECUTED. Conversely, the arbitrary literal "synthetic" reaches a favorable fixture label without an actual custody receipt. Thus the code teaches status distinctions but cannot authenticate a real producer or approval.

Practice and criterion: Submit the five output lines, a dependency/owner map and a two-sentence handoff that explains a missing authorized alternate. Full credit requires the R1–R8 release boundary, an observable training test and the difference between proposed, approved and actually collected evidence. R9 cannot be used at Round A merely because its source event time is earlier than the 09:05 review.

Synthesis: Readiness requires an owner-governed answer to a bounded question, not a green dashboard label. Module 2 will test the source, clock and collection decisions. This addendum creates no new Harbor Library incident record.

1.11 Common errors and chapter synthesis

• Confusing suspicion with confirmation. Use a hypothesis and state what would confirm or weaken it.
• Skipping the service owner. A technically plausible action can cause avoidable harm to users.
• Losing the timeline. Record source timestamps, timezone and collection time.
• Expanding scope silently. Ask before collecting or changing systems outside authority.
• Treating a backup status as a restoration test. A successful backup run is one fact, not a recovery guarantee.
• Treating an absence in incomplete logs as evidence of absence. State the collection limit.

Readiness is the ability to answer, under pressure, who owns the service, who can approve a decision, where trustworthy evidence can be found, and how a decision will be reviewed. This chapter prepares the alert-triage and evidence-preservation work in Module 2.

Worked checkpoint

At 09:05 the case contains only R1–R8. A decision card may recommend a restricted check with its owner, alternative and 09:15 review trigger; it must not report an interview, export or service change as performed until a separate execution record exists.

Practice — Lesson 05

EX004 — Scope boundary

Objective: apply an authorization boundary to a tempting next action. Inputs: the section 1.4 scope statement and R1–R8. Output: a short scope decision with proposed action, permitted objects and operations, reason for rejection, contained alternative, and stop or escalation condition. A learner wants to search a real public library website for a matching account name. Explain what the eight supplied records permit instead, and write a hypothetical request for the additional detail if it would matter to the case. A score of 2 explicitly excludes real-site access and names the responsible approver for any future expanded scope.

AR1 supplementary task (after the required artifact):

Additional check: In the existing short scope decision rejecting a real-world library search, state what the learner would need to see in an authoritative, current, scope-bound approval before any future new collection could even be proposed to the designated custodian. Use AR1 to name a stale-register or excessive-object-scope failure as a separate readiness example, not as an incident fact.

Full-credit criterion: Keep the original permitted objects, reason for rejecting real-site access, contained alternative and stop/escalation condition. An expired delegation or unverified confirmation path must block the proposed additional collection. No simulated valid AR1 result grants permission over a real website.

Worked answer: EX004 in the final appendix.

EX007 — Minimal incident record

Objective: open a case that another analyst can continue. Inputs: R1–R8 and the 09:00 intake checkpoint. Output: exactly seven labeled fields: case ID and open time; service; reporter and source; observed signal with record IDs; current assessment and uncertainty; permitted scope and authority; next question, owner and review time. Related details may share a field. A score of 2 retains the T-104 help-desk context from section 1.5, distinguishes the report from an independently checked booking state, and does not claim the later 09:05 decision was already executed at 09:00.

Behavior-baseline extension: Keep exactly seven opening fields. In the existing uncertainty field, note that a recorded edit and patron report do not establish the owner-approved correct current booking state. Do not import the separate BSL1 fixture or a later decision.

Worked answer: EX007 in the final appendix.

EX009 — Decision alternatives

Objective: justify a proportionate 09:05 decision under uncertainty. Inputs: R1–R8 and the section 1.9 gate. Output: a two-row option matrix for (A) seeking a temporary restriction of desk-a and (B) preserving R1–R8, asking the training owner and reviewing before restriction. Record expected benefit, possible service or delay cost, approver, observable success or failure and a 09:15 review trigger for each. Choose one provisionally and explain what new evidence would reverse it. A score of 2 identifies a separate approval for restriction and does not describe either risk as an already observed event.

Extension: Add a falsifier and a business negative check to both original options. State which observation would make the learner reconsider a decision to wait and which observation would indicate an account restriction disrupted legitimate work.

For full credit: A 2-point answer requires distinct approval, execution and verification states, not merely a preferred option.

PATH1 supplementary task (after the required artifact):

Additional requirement: Keep both original 09:05 options and their approvals. Add a clearly marked counterfactual: if a future authorized test found staff edits impaired but manual request intake possible, identify the one user promise that remains permitted and one that is prohibited. Do not replace the original evidence decision or invent a new R-series item.

AR1 supplementary task (after the required artifact):

Additional check: Keep the original two-option 09:05 matrix, R1–R8-only evidence and review triggers. For the restriction option, add a pre-incident preparedness question: if the service owner or permitted alternate could not be verified through the current register, would the analyst still have authority to impose the restriction? Explain the safe answer without importing AR1's fictitious people or its September rehearsal as a case result.

Full-credit criterion: Recommendation and approval remain separate; no missing reply is treated as permission. The chosen provisional option continues to be justified by available case evidence, not by a fabricated expired owner at 09:05.

Worked answer: EX009 in the final appendix.

EX012 — Practice record

Objective: make a bounded decision auditable. Inputs: R1–R8, the fictional 09:05 checkpoint and section 1.3's authority matrix. Output: one decision log with time, action, reason with source IDs, approving role, executing role, evidence-copy scope, rejected alternative, next review time and reversal trigger. The scenario grants classroom permission for the bounded copy; do not describe a production export. A score of 2 states the question to the service owner as pending until answered and preserves uncertainty about account control.

Extension: Record an explicit state for each activity: proposed, approved classroom analysis, performed classroom copy if actually done, or not performed. Leave the proposed training-owner answer pending until supplied.

For full credit: A 2-point answer never reports a hypothetical request as a completed interview or a production evidence collection.

Worked answer: EX012 in the final appendix.