Chapter 5 — Investigation, hypotheses and timeline building

Lesson map

Lesson 05 published. Map, example, EX021.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 Normalize without losing the source"]
  N2["5.2 Later cards C11 and C12"]
  N3["5.3 Three competing explanations"]
  N4["5.4 Choose requests by decision value"]
  N5["5.5 A worked 09:26 handoff"]
  N6["5.6 Investigation is not narrative completion"]
  N7["5.7 Graph joins require field semantics, not coincid"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX021"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 Normalize without losing the source"]
  N2["5.2 Later cards C11 and C12"]
  N3["5.3 Three competing explanations"]
  N4["5.4 Choose requests by decision value"]
  N5["5.5 A worked 09:26 handoff"]
  N6["5.6 Investigation is not narrative completion"]
  N7["5.7 Graph joins require field semantics, not coincid"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]

[Learning outcomes]
    |
    v
[5.1 Normalize without losing the source]
    |
    v
[5.2 Later cards C11 and C12]
    |
    v
[5.3 Three competing explanations]
    |
    v
[5.4 Choose requests by decision value]
    |
    v
[5.5 A worked 09:26 handoff]
    |
    v
[5.6 Investigation is not narrative completion]
    |
    v
[5.7 Graph joins require field semantics, not coincid]
    |
    v
[Worked example] --> [Exercise EX021]

Learning outcomes

The learner can build a source-traceable timeline, distinguish temporal coincidence from a causal join, maintain at least two competing explanations, identify a least-invasive discriminator and issue a handoff that a containment planner can use. The chapter teaches a decision-quality investigation rather than attribution to a person or a complete forensic reconstruction.

5.1 Normalize without losing the source

A timeline is a derived view. It should link each entry to the unchanged source card and show event time, confidence in the time basis, case receipt and significance. For C04, keep raw 08:54 and normalized estimate 08:58. For C10, keep the display's 11:21 UTC+02:00 and the conditional 09:21 conversion. For C02, record the reporter's “around 09:00” separately from the 09:04 ticket receipt. Do not turn that recollection into a timestamp precise to the minute or silently move a later-released card into the 09:04 decision.

At 09:22, the strongest joined facts are still limited. C09 gives s-77 and client runner-03 within its supplied export, while C03 gives a sign-in summary with s-77; C04 names runner-03 but does not provide a session ID. C05's application record names q-144 and the shared account but has a blank session field. A source-reliable join requires matching identifiers with verified semantics or a tested system relationship. Matching account labels and close times generate a useful hypothesis, not a causal link. The documented C09 provenance gap further limits how confidently one can rely on the CSV as a complete source.

5.2 Later cards C11 and C12

At 09:24 UTC, support provides C11: an operator says S42 “might have been included in a late approved change.” No change ticket or addendum is attached. This is a lead to check, not a retroactive amendment to C06. At 09:26 UTC, the application custodian provides C12: a read-only view of the C05 audit record shows request q-144 with a self-reported job tag batch-17. The tag records what the application received; it is not proof the scheduled job actually originated the request. The custodian has not supplied a validated job-run record, session/request join or current S42 database state. These cards are now usable; they were unavailable at prior checkpoints.

Lesson table; scroll horizontally to read all columns →

The apparent ordering of C02's noticed symptom and C05's edit is a useful warning: a symptom noticed “around 09:00” can be earlier than a recorded 09:01 edit. This may reflect memory imprecision, earlier unrelated behavior, a time-base problem or more than one event. Do not repair the contradiction by moving C05 or by assigning an unprovided clock offset to the API. Instead, ask for a narrower support interview or a traceable front-end record. Such tension is often where an investigation finds its next good question.

5.3 Three competing explanations

Use a hypothesis table, not a single favored story. A hypothesis should specify a mechanism, supporting and contradictory observations, a discriminator that might fail, and what decision it would affect. Confidence is provisional and should not be collapsed into the case priority.

Lesson table; scroll horizontally to read all columns →

Do not label H1 “confirmed” just because three fields sound consistent. They arise from distinct systems with different semantics, and the decisive join is missing. H2 does not become likely solely because C06 lacks S42; an unseen addendum remains possible. H3 cannot erase C05; it must account for the edit or accept that display and data effects are separate. This is why the next evidence request should be chosen for discrimination, not volume.

5.4 Choose requests by decision value

At 09:26, a bounded S42 authoritative-state check is likely to change the service-impact assessment and inform any containment plan. It should return the slot's current state, last change ID and time if available, without exporting other learners' records. The service owner or custodian must authorize it. A job-run record keyed by q-144 could distinguish H1 from some H2 variants; first ask whether the job actually stores trustworthy request IDs. An approved change addendum could resolve the C06/C11 tension but would not, alone, show the application executed only approved slots. An identity access trail could strengthen or weaken H2, but account sharing may still prevent individual attribution.

Each request should have an expected decision use. “Please send all logs” has no bounded answer and often creates new privacy and provenance risk. “For q-144, provide the source run ID, producer, event time, approved slot list and original record identifier for 08:50–09:05, if available” can fail clearly if no such record exists. That failure is information about visibility, not proof of a particular mechanism.

When evidence conflicts, keep competing versions and a review point. A timeline should not erase C11's unverified claim when C06 shows a narrower visible approval. A second analyst should be able to see the source, release time and reason for each inference. The handoff to Chapter 6 should include a conditional action matrix: if S42 is presently wrong and a continuing write path is observed, ask the appropriate owners to compare containment options; if state is correct and the job record explains q-144 under approved scope, consider downgrade with documented criteria; if records remain incomplete, preserve the uncertainty and avoid an irreversible broad change. None of those branches is an observed result in the current manuscript.

5.5 A worked 09:26 handoff

“CTN-IR-014 remains P2 provisional at 09:26. C05 reports an S42 edit through q-144; C12 adds a self-reported batch-17 tag. C03/C09 report session s-77 from runner-03; C04's corrected browser time coincides but lacks a join key. C06 lists approval only for S40–S41, while C11 claims a possible addendum without evidence. C10 depicts an unavailable page, not authoritative state. C09's object integrity and full collection method remain undocumented. Request owner-approved S42 state check and bounded job-run/addendum records. Do not assert a human actor or execute account-wide containment. Reassess on those results or before any further source expiry.” This is a compact artifact another shift can challenge.

5.6 Investigation is not narrative completion

By the start of this chapter, CTN has a preparation worksheet, a support symptom, identity and endpoint signals, an API edit, a narrow visible approval, a shared-account explanation, an expiry warning, an IdP export with acquisition gaps and a screenshot with uncertain display context. These items are evidence about specific claims. They do not combine automatically into a single story.

An analyst may notice that the event times cluster near 08:58–09:01. That pattern generates a question: "Could the reported sign-in, runner process and S42 write be part of one mechanism?" It does not answer it. A coherent story is especially seductive when an application audit and IdP record share an account label. Shared account names are weak identity keys; they may represent several sessions, multiple operators, jobs or credential uses. The missing relationship between session s-77 and request q-144 remains pivotal.

Keep an explicit claim-to-source map. Each assertion needs source ID, exact field or excerpt, time basis, acquisition quality and a confidence/limitation note. Separate three statement types:

• Documented observation: "C05 reports S42 edit at 09:01 with request q-144 and a blank session field."
• Analyst inference: "A shared identity could link a human or automated action to the edit, but no validated path is provided."
• Conditional decision: "If a scoped state check finds continuing harmful writes, escalate options to the service and change authorities."

A fourth statement type, verified result, requires the actual approved check and its recorded output. Nothing in C02–C12 is a containment execution or a verified restoration. The safest useful investigation is one that exposes what would make its current explanation wrong.

5.7 Graph joins require field semantics, not coincident labels

Represent events as nodes and asserted relationships as typed edges. A same-source match may be meaningful when the producing system guarantees identifier uniqueness in the relevant scope. A cross-source match requires evidence that both systems use the same namespace and emit the identifier for the same transaction. A causal edge needs more than equality; it needs a validated mechanism and appropriate temporal/semantic context.

At 09:26, C03 and C09 report s-77. In the supplied C09 rows, s-77 is associated with client runner-03. C04 separately reports a browser process on device runner-03. This device/client text similarity makes a useful investigative lead but is not a direct process-to-session join. C05 and C12 both bind q-144 to the API edit; C12 adds a self-reported batch-17 tag. That label is not cryptographic proof that the scheduled job originated the request or had the S42 edit within approved scope.

A dangerous shortcut is to cross the graph from s-77 to q-144 merely because both records include svc-enroll around the same time. The API's session field is blank. Unless another permitted source supplies a verified shared identifier or tested relationship, the direct edge is missing. Neither a confident prose description nor a dashboard correlation score creates that evidence.

The distinction is especially important for accountability. Even a validated task-to-request join (which has not been released at the C12 checkpoint) would identify a technical mechanism, not necessarily the human who configured, triggered or controlled the task. Do not import later chapter findings such as C13–C20 into the 09:26 analysis.

5.8 Reproducible offline join-audit exercise

This Python 3 fixture demonstrates which explicit identifier equalities are visible within supplied synthetic records. It does not query CTN, validate the provenance of C09, compute a human identity or infer a causal relationship from account labels.

records = [
    ("C03", "identity", {"session_id": "s-77", "account": "svc-enroll"}),
    ("C09", "identity", {"session_id": "s-77", "client": "runner-03"}),
    ("C04", "endpoint", {"device": "runner-03"}),
    ("C05", "application", {"request_id": "q-144", "account": "svc-enroll", "session_id": None}),
    ("C12", "application", {"request_id": "q-144", "claimed_tag": "batch-17"}),
]
allowed = {
    ("C03", "C09", "session_id"),
    ("C05", "C12", "request_id"),
}
for first, second, key in sorted(allowed):
    a = next(fields for card, _, fields in records if card == first)[key]
    b = next(fields for card, _, fields in records if card == second)[key]
    print(f"C5|{first}<->{second}|{key}|{a}|match={a == b}")
print("C5|s-77_to_q-144|DIRECT_JOIN=NO")

Executed output for this exact fixture:

C5|C03<->C09|session_id|s-77|match=True
C5|C05<->C12|request_id|q-144|match=True
C5|s-77_to_q-144|DIRECT_JOIN=NO

The two "match=True" statements test value equality for the specified fields. They do not independently verify source provenance or full identifier semantics. The final "DIRECT_JOIN=NO" is an explicit analyst annotation based on the absent shared key. It is not the result of a hidden graph algorithm. The distinction between equality and validated causation is part of the learning outcome.

Safe negative test: insert a proposed edge ("C03", "C05", "session_id") and inspect the values. C05's session is None, so the match cannot be established. An invalid or missing field should lead to an unknown edge, not an automatic assertion that the two events are unrelated. Similarly, adding a shared account comparison would return equal labels but would not make the join trustworthy. A source validation request must ask the relevant owners whether identifiers are globally unique, reused, transformed or omitted along any route.

5.9 Rank evidence requests by decision value and acquisition risk

A good request is narrow enough to fail. Compare two candidate records.

Request A: authoritative S42 state and last-change context. Owner: application/service custodian after local approval. Scope: S42 only, selected status/version/last request ID and timestamp, minimal personal data. Decision value: whether an ongoing service state problem exists and how urgently a scoped intervention might be needed. Possible outcomes: currently wrong state; currently correct state; query unavailable/unauthorized; ambiguous version evidence. None has been observed at 09:26.

Request B: preserved q-144 job-run and identifier semantics. Owner: scheduler/job and application custodians under permitted case scope. Scope: interval surrounding 09:01, run ID, task, produced request ID, expected slot list and source-object reference. Decision value: whether H1 has a substantiated technical route. Possible outcomes: validated run/request match, mismatched run, missing fields or unavailable producer. No outcome has yet been received. A self-reported batch-17 string is insufficient.

C11's suggested change addendum is an important separate targeted check with the change authority. It does not eliminate the need to show actual behavior and state. These requests should be queued against acquisition urgency, privacy sensitivity, owner availability and potential change to response planning. "Export everything to investigate H2" increases risk while obscuring the exact decision at stake.

A decision table can ask: if S42 is wrong and a continuing harmful write is supported, prepare a scoped intervention proposal for Chapter 06; if state is correct and q-144 matches authorized work through a validated record, consider a documented downgrade review; if results remain missing, preserve unknowns, document the cost of additional collection and avoid broad changes without authorization. Those are future branches, not current observations or preapprovals.

5.10 Compare false causal certainty with actionable uncertainty

Bad conclusion: "At 08:58 attacker on runner-03 signed in as svc-enroll, used batch-17 to edit S42 at 09:01 and hid the approval." This asserts an attacker, device-to-session join, job origin, causal link and motive absent from C02–C12. C11's operator statement does not prove approval was hidden. Technical-sounding certainty is not the same as source-backed reasoning.

Good conclusion: "C03/C09 report s-77 and C09 associates a runner-03 client; C04 independently reports a runner browser at a corrected 08:58 estimate. C05/C12 report q-144 and a self-reported batch-17 tag. These items remain connected by leads rather than a validated session-to-request join. The visible approval omits S42, while a claimed addendum is unverified. Obtain approved S42 state and job/approval records before choosing a control."

The second conclusion is operationally stronger: the supervisor can identify the exact missing evidence and the proposed owners. It also protects later lessons from retroactively changing the Chapter 05 checkpoint. Mechanism, actor, intent and authorization are separate questions with distinct evidence requirements.

5.E1 A timeline is an argument with provenance, not an ordered story

A professional timeline should preserve four dimensions per row: original producer event time (and precision), a normalized comparison time with its transformation, the case's knowledge/receipt time, and the exact claim the record can support. If the source says approximately 09:00, its normalized comparison time is still approximate. If a device shows 08:54 on a clock declared four minutes slow, the classroom estimate is 08:58; a professional should retain the raw 08:54 and ask about the offset's uncertainty before treating the equality with the 08:58 IdP sign-in as an exact overlap.

The timeline's scope should be fixed before presenting it. At 09:22 C09 has been received and C10 shows a displayed unavailable slot, but neither C11 nor C12 exists in the learner's released state. A table assembled at 09:26 may use both later cards if marked as released at their actual times; a frozen 09:22 decision may not be silently rewritten with the new batch-17 tag. An incident review should retain the earlier decision even when the hypothesis changes.

Consider the following useful time uncertainties. C02 says a symptom was noticed around 09:00, while C05 reports an S42 edit at 09:01. If both descriptions are reliable, the symptom could precede that edit. It may concern an earlier unrelated problem, a clock difference, caching, or imprecise recollection. The correct procedure is not to move the support time to 09:02 to make a fluent story. Record the tension; then ask for a new, authorized discriminator such as a front-end trace linked to the reported symptom. Investigation quality improves when contradictions remain visible.

At 09:26 a source-aware timeline can name C03 and C09's matching s-77, C09's claimed client runner-03, C04's independently observed runner browser, C05's application request q-144, and C12's self-reported batch-17. Its graph must not add s-77 → q-144: the application's session field is blank, and the job tag lacks proven producer semantics.

5.E2 An investigative graph needs different edge types

An investigation graph represents records as nodes and typed, challengeable links as edges. A source identifier shared within one producer can support a bounded equality statement if that producer's uniqueness/namespace contract is established. A label shared across two producers is weaker: the strings may use different namespaces, represent proxies or omit translation steps. A causal link is stronger still and needs a tested mechanism and matching operation context. Finally, a human-actor attribution needs independent evidence beyond an account, task or session label, especially when C07 explicitly says the account can be used by both automation and emergency operators.

A responsible graph therefore distinguishes:

Lesson table; scroll horizontally to read all columns →

This model is useful because evidence can narrow a mechanism without identifying a person. An approved scheduler run later found to emit q-144 might support H1 for a technical path, but still would not establish who configured the task. The present checkpoint does not contain that validated run. Equally, C06's missing S42 in the visible calendar raises concern but does not prove that no separate approval was ever granted.

5.E3 Choose a discriminator that can fail, not a request for “everything”

A hypothesis becomes operational when the team names which result would strengthen it, which would weaken it, and what happens if the source is incomplete.

H1: an automated job wrote the wrong slot. Current leads: scheduled use of the shared account, runner-03 client field in C09 and C12's tag. Against it: no preserved, validated job run for q-144, and visible approval includes S40/S41 only. Request the minimal job-run record including source, run ID, request ID, actual slot selection, event time, code/task version and job approval. If a complete, authenticated run manifest for that interval excludes q-144, H1 as an explanation of that request weakens. If the manifest is partial, absence remains unknown.

H2: the shared account was used outside the approved task scope. Current leads: C05 S42 edit under svc-enroll, while C06 does not list S42. Alternative: C11 reports a possible addendum; emergency humans may share the account. Request the approved change ledger/version and bounded identity records, with documented field semantics. A valid S42 addendum plus coherent job/request path could weaken an unauthorized-use hypothesis but would not by itself establish that the current slot is correct. A denied collection does not automatically strengthen H2.

H3: the displayed symptom differs from current backend state. Current leads: C02 and C10 are observations of a report/image, neither an authoritative S42 read. Against a pure display-only theory: C05 records an actual application edit which H3 must explain or accommodate. Ask the service owner to approve an authoritative S42 value/version read and a separately observed uncached view, retaining timestamps. An incorrect authoritative value would prevent the analyst from closing the incident as solely a display issue; a matching correct backend and inconsistent displayed view could strengthen the display/caching branch for that time.

The strongest test is not necessarily the one most likely to confirm the analyst's favorite theory. It is the one that changes a decision under the available authority and loss risk. The service-owner S42 state check affects potential patron harm; the job-run/request-ID check affects the mechanism; the addendum affects authorization. Keep these questions separate even if a single custodian can coordinate them.

5.E4 How to handle negative evidence without overpromising

“No matching record” can mean different things. A scoped, healthy, known-complete query may support the absence of a particular recorded event within its declared window. A query with unspecified filters, delayed ingestion, unavailable historical records or a nonfunctional producer supports much less. If the cross-source identifier is missing entirely, no query on account label and time can manufacture it. A false claim that “no join means the sign-in and edit are unrelated” is as unwarranted as “the sign-in caused the edit.”

The collection quality of C09 matters even though its s-77 row is informative: missing original-object ID, byte count and digest limit claims about the acquired copy's integrity; none of those gaps means its values must be false. Preserve uncertainty instead of substituting either trust or distrust as a certainty. Another responder may later obtain those missing receipts, validate the same bytes and change the confidence rating, while the original 09:26 record remains versioned.

At a supervised decision point, the analyst can record confidence in the leading mechanism = unresolved, confidence that a producer reported S42 changed = supported within the supplied application record, and confidence that current backend state is incorrect = not measured. Severity and intervention urgency can still be nonzero. Confidence must be attached to a particular claim, not to the entire case as if one percentage explained every dimension.

5.E5 Offline lab C5X — compare identifier equality with an absent join

Environment: Python 3 standard library, no files, requests, credentials or source modifications. The five edges are invented representations of the bounded source-card claims, and C05-NEGATIVE is an exercise-only adversarial control, not another CTN case card.

edges = [
    ("C03-C09", "same_namespace", "s-77", "s-77"),
    ("C05-C12", "same_namespace", "q-144", "q-144"),
    ("C09-C05", "cross_namespace", "s-77", None),
    ("C09-C04", "cross_namespace", "runner-03", "runner-03"),
    ("C05-NEGATIVE", "same_namespace", "q-144", "q-999"),
]

def classify(edge):
    name, namespace, left, right = edge
    if left is None or right is None:
        return "UNKNOWN_MISSING_KEY"
    if left != right:
        return "UNMATCHED_VALUE_IN_TEST"
    return ("VALUE_EQUAL_SEMANTICS_UNVERIFIED"
            if namespace == "same_namespace"
            else "LABEL_EQUAL_NAMESPACE_UNVERIFIED")

for edge in edges:
    print(edge[0], classify(edge))

Executed output (five lines):

C03-C09 VALUE_EQUAL_SEMANTICS_UNVERIFIED
C05-C12 VALUE_EQUAL_SEMANTICS_UNVERIFIED
C09-C05 UNKNOWN_MISSING_KEY
C09-C04 LABEL_EQUAL_NAMESPACE_UNVERIFIED
C05-NEGATIVE UNMATCHED_VALUE_IN_TEST

The result is not causal proof. Even when values match, the producer's key namespace and provenance require independent verification. The direct session-to-request edge remains unknown because no shared key is supplied. Adversarial control: replace the None in C09-C05 with "s-77"; the displayed status would change to LABEL_EQUAL_NAMESPACE_UNVERIFIED, not to confirmed causal join or actor attribution. Replacing the negative q-999 with q-144 changes only the equality status in that controlled fixture. Neither mutation changes C05 or C12 source facts.

Required learner artifacts: Five statuses, a three-hypothesis matrix, one graph distinguishing observed and unobserved edges, two least-privilege evidence requests, and a 09:26 handoff preserving current source gaps. Five-point local scoring: one for correct equalities, one for the missing link, one for cross-namespace ambiguity, one for the negative control and one for evidence requests that name owners and falsifiers. A learner who names a human attacker or reports batch-17 as a validated run fails the evidence boundary.

5.E6 An operationally usable 09:26 supervisor handoff

At 09:26 the analyst's next decisions should be presented as conditional, rather than a recommendation to take immediate broad action. If a permitted authoritative S42 check later finds continuing wrong slot state or new harmful writes, the incident lead can ask the service/identity owners to compare Chapter 6 controls and their cost. If a verified q-144 job-run and complete approved S42 scope later arrive, the team can review whether a downgrade is defensible. If the owner or source is unavailable, the record should say which claim is blocked and what preservation or escalation remains possible; it should not silently treat lack of evidence as safety.

A complete handoff has a decision clock in addition to an event clock. At 09:26 C11 and C12 are usable. A reviewer must not import Chapter 6's later C13–C19 scope, approvals, execution receipts or controls into the assessment. Nor should a person be named behind svc-enroll: this case has a shared identity and no validated actor-to-operation edge. The next chapter's function is to plan reversible, owner-approved protection options, not to reward certainty unsupported by this chapter.

Chapter synthesis: A source-traceable timeline and a typed evidence graph produce actionable uncertainty: identified service question, current supported observations, explicit contradictions, missing joins and prioritized requests. Keeping the missing links visible allows a supervisor to take proportionate steps if harm becomes verified, without treating a hypothesis as an observation.

Common mistakes and limits

• Writing a smooth story that hides contradictions. Preserve the approximate C02 symptom time and the exact C05 event time as separate sources.
• Using a self-reported tag as proof of origin. Verify the producer and join-key semantics.
• Allowing a later statement to rewrite an earlier checkpoint. Version the timeline and note C11's 09:24 release.
• Promising attribution a shared account cannot provide. The team may still establish scope, impact and safe control options without naming a person.
• Demanding a broad export as the next step. Ask the smallest question that changes a decision, under the appropriate approval.

Practice: hypothesis review board

Three learners defend H1, H2 and H3, each citing source IDs, one tension and a falsifiable next request. A fourth learner acts as recorder and rejects statements that use C11 or C12 before their release, convert missing data into negative evidence, or confuse the source clock with receipt. The board then builds a revised 09:26 handoff. No production access or live investigation is involved.

Exercises — subject 5

EX021 — Source-traceable timeline. Input: C02–C12. Produce at least seven entries with event time or range, raw-to-normalized annotation where needed, case receipt/release, source ID and a limitation. A 2-point result preserves C02's approximate time and C10's conditional conversion.

EX022 — Join audit. Input: C03–C05, C09 and C12. Draw supported and unsupported links among s-77, runner-03, q-144 and batch-17; name the one identifier or producer check needed for a direct join. A 2-point result does not claim s-77 caused q-144. Reproduce the C5 offline join-audit output in §5.8 and distinguish field equality from a validated causal edge.

EX023 — Hypothesis matrix. Input: C05–C12. Write H1, H2 and H3 with one supporting observation, one counterpoint and a falsifiable discriminator each. A 2-point result treats the job tag and possible addendum as leads, not findings.

EX024 — Minimal next request. Input: the 09:26 record. Choose two requests that most directly affect service impact and causal explanation; specify custodian, scope, approval, expected artifact and possible outcome that would change the plan. A 2-point result avoids bulk export and distinguishes a request from a received result.

EX025 — Professional handoff. Input: your EX021–EX024 artifacts. Write a 140–200-word 09:26 handoff with priority and rationale, supported timeline, two unresolved explanations, evidence quality gap, proposed requests, forbidden overclaim and next decision gate. A 2-point result could be used by a supervisor to plan Chapter 6 without inventing an approval.

Subject synthesis and next step

This first five-chapter sequence moves from prepared ownership to bounded authority, triage, preservation and competing explanations. It has not yet performed containment, eradication or recovery. Chapter 6 uses the resulting handoff to compare bounded controls and approval gates. Before moving on, a learner should be able to tell another responder what was actually observed, what remains a hypothesis, which source might resolve it and who has the right to act.