Scope, case record and bounded first decision

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:

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.

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.

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:

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.

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.

Continue studying — lesson 05 of at least 20

← Lesson 04 · Course lesson index · Lesson 06 →

Continue to the next authored daily lesson.

Continue studying — chapter 01 of 04

← Course overview · Course lesson index · Chapter 02 →

The next chapter contains the following instructional week.