Chapter 7 — Eradication and verification

Lesson map

Lesson 07 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["7.1 Four different statements about cause"]
  N2["7.2 New cards C20–C23"]
  N3["7.3 Build a cause-to-fix verification contract"]
  N4["7.4 What was actually done by 10:07"]
  N5["7.5 Reproducible, read-only manifest comparison"]
  N6["7.6 Proof of a mechanism requires a chain, not a mat"]
  N7["7.7 Inventory deviation, operational failure and mal"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["7.1 Four different statements about cause"]
  N2["7.2 New cards C20–C23"]
  N3["7.3 Build a cause-to-fix verification contract"]
  N4["7.4 What was actually done by 10:07"]
  N5["7.5 Reproducible, read-only manifest comparison"]
  N6["7.6 Proof of a mechanism requires a chain, not a mat"]
  N7["7.7 Inventory deviation, operational failure and mal"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes and connection]
    |
    v
[7.1 Four different statements about cause]
    |
    v
[7.2 New cards C20–C23]
    |
    v
[7.3 Build a cause-to-fix verification contract]
    |
    v
[7.4 What was actually done by 10:07]
    |
    v
[7.5 Reproducible, read-only manifest comparison]
    |
    v
[7.6 Proof of a mechanism requires a chain, not a mat]
    |
    v
[7.7 Inventory deviation, operational failure and mal]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes and connection

The learner can state a cause hypothesis with evidence limits, distinguish stopping one process from removing its possible persistence paths, design positive and negative verification, and keep the service-impact owner in the decision. Chapter 6 contained one slot temporarily. This subject asks what mechanism produced q-144 and which configurations must be assessed before the hold expires. The result is a bounded eradication decision, not a claim that a named attacker was found.

7.1 Four different statements about cause

“The unexpected task exists,” “the task's recorded run produced q-144,” “the task was not in the approved inventory,” and “a person intentionally installed it” are four different claims. A source can support the first three while leaving the fourth unknown. A professional case record should name the producer and collection method for each, then identify what would disconfirm the proposed causal chain. For example, a task run record with a request ID in a different namespace would weaken the task-to-API join. If the application custodian verifies the namespace and exact request ID, confidence in the mechanism rises, but account sharing and absent actor fields can still prevent attribution.

Eradication has two parts: remove or correct a cause if sufficiently identified, and test whether the harmful path or configuration can recur. Deleting a suspicious object without preserving its state may destroy the very record needed to verify the mechanism. Conversely, preserving it does not require leaving it active forever. The owner must approve a sequence: preserve a bounded configuration and task-run record, plan the change and rollback, execute through an authorized operator, then verify both the expected improvement and the absence of unwanted side effects. The NIST SP 800-61 Rev. 3 risk-management framing supports coordinated response and improvement; the exact CTN task and change procedure are invented for this course.

7.2 New cards C20–C23

At 09:46, the application custodian releases C20: a preserved scheduler record for runner-03 shows an unrecognized task named sync-override, registered at 08:47, with a run at 09:00 that logged API request q-144 for S42. The custodian and application owner compare a known-good request against the scheduler and API records, confirming that these request IDs share a namespace and that C05's q-144 is the same request. This supports the mechanism “this task issued the S42 edit.” It does not prove who registered the task, that s-77 initiated it, or that the task was malicious rather than mistaken work.

The approved C17 hold is due to expire at 09:47. C21, a separate case record at 09:46:30, documents fresh service-owner and incident-lead approval to extend the S42-only hold to 10:07 after reviewing C20, the continued enrollment cost and the risk of another edit. The application operator records the extension at 09:46:45 under change g-23. It inherits the limited scope, monitoring and rollback owner, and adds an explicit 10:06 review before expiry. C16 covered the initial ten minutes only; C21 records a new decision for the longer interval. An extension must not be inferred from the analyst's wish to keep the control or from the mere existence of C20. The C19 one-route observation still does not certify all-route coverage.

At 09:50, the identity custodian releases C22: a separately retained configuration-audit source reports a recovery-method addition to svc-enroll at 08:52, with its actor field blank. This is not a reconstruction of the detailed sign-in source in C08, which was stated to expire at 10:00; the two sources have different retention and fields. The recovery-method record indicates a possible continuing access path, but the team has not yet tested whether it works. At 09:54, C23 records the job owner's comparison with the approved task inventory and the identity owner's comparison with the official change ledger. Neither sync-override nor the recovery-method addition appears as an approved change through that checkpoint. The owners classify the changes as unapproved configuration changes. That process classification still does not identify a person or motive.

Lesson table; scroll horizontally to read all columns →

7.3 Build a cause-to-fix verification contract

A useful eradication contract is an explicit chain: observed mechanism → proposed control → owner approval → preserved baseline → execution receipt → positive test → negative test → monitoring window → reopen condition. For the task, the positive test is that its status is disabled and it does not run at its next expected schedule. A negative control is that the legitimate batch-17 S40/S41 job still has a working path. The latter matters because disabling the entire shared account would appear to suppress the suspect task while also breaking service. The checks should use approved observations or an isolated test copy; a learner must not create a live write attempt from this textbook.

For the recovery method, the identity owner should determine whether the unexpected method is active, obtain the required approval to remove it, and plan credential/session changes with service dependency checks. A check that the old s-77 session is inactive would support a narrow containment property; it would not prove that every other access path has been removed. The team also needs to preserve enough pre-change record to understand the unapproved configuration. Do not publish the recovery token or any secret in the case file. The fictional cards contain no such values.

The single-task conclusion is stronger than Chapter 5's hypotheses, so revise H1/H2/H3 carefully. The official batch-17 explanation H1 is weakened by C14, while a newly discovered different task explains q-144 more directly. H2's “emergency human used the shared account” remains possible as a registration mechanism but is not proven. H3's pure display-only mechanism is contradicted by C13's stored-state change. The updated case hypothesis is: “An unapproved sync-override task issued q-144, and an unapproved recovery-method change may be a separate persistence concern; actor and relationship between them remain unknown.” It is a versioned inference, not an incident-close statement.

7.4 What was actually done by 10:07

C24 records a scoped decision and outcome. At 09:59, the response lead and service owner approve disabling only sync-override, after the application custodian preserves its configuration and bounded run record. They do not approve deleting evidence or disabling svc-enroll. At 10:03, an authorized application operator records that the task was disabled. A read-only scheduler status check agrees, and no further run appears through 10:07. The observation window is short, and the recovery method from C22 remains unresolved. No source in C24 proves that the task cannot be re-created, that another runner lacks a copy, or that all account sessions are invalid. The word eradicated would therefore overstate the case at this checkpoint.

At 10:06 the owner reviews the S42 hold. The task is disabled, there are no observed new S42 edits since C19, and continuing the hold would further block legitimate enrollment. The owner chooses not to renew it past the approved 10:07 expiry, with a read-only S42 write monitor and a stop/escalation condition if a new unexpected edit is observed. That is a risk decision under uncertainty, not proof that the service is safe. It leaves a short residual window before Chapter 8's identity and recovery actions; the handoff should name it. A team should not silently extend a time-bounded control to make a tidy story.

7.5 Reproducible, read-only manifest comparison

The following Python 3 snippet uses only invented identifiers and no files or network. It compares one approved job-run set with the observed CTN task-run set. It is a coverage aid, not malware detection or actor attribution.

approved = {"batch-17": {"q-140", "q-141"}}
observed = {
    "batch-17": {"q-140", "q-141"},
    "sync-override": {"q-144"},
}
approved_requests = set().union(*approved.values())
observed_requests = set().union(*observed.values())
print("unexpected tasks:", sorted(set(observed) - set(approved)))
print("requests outside approved run:", sorted(observed_requests - approved_requests))

unexpected tasks: ['sync-override']
requests outside approved run: ['q-144']

This result says that, in this supplied two-run fixture, one task and request are outside the approved set. It does not prove the inventory is complete for all runners or that the new task was installed intentionally. Changing the approved set in a separate V7 variant would change the classification; a reviewer should preserve both inputs and the reason for any update.

7.6 Proof of a mechanism requires a chain, not a matching word

A response analyst should separate three levels of explanation. Correlation says two events occupy similar time or share a label. Operational mechanism says a demonstrated component or workflow produced an identified outcome. Human attribution says a particular principal intentionally or accidentally caused that mechanism. These claims demand different evidence. The first may follow from time overlap; the second generally needs validated identifier semantics and producer records; the third may need additional identity, access, operator and authorization material.

For CTN, C12's self-reported batch-17 tag initially appeared to explain q-144. It was a field supplied by one event producer, not verified execution provenance. C14 later provided a custodian-confirmed complete manifest for that approved run containing q-140 and q-141 but not q-144. C20 provides the stronger causal link: its preserved task-run record identifies q-144, and a custodian verifies it is in the same request namespace as the application evidence. Therefore “sync-override issued the observed S42 edit” is supported more tightly than “batch-17 issued that edit.”

An analyst should still explicitly consider collision, transformation and time semantics. A request label is useful only after checking which subsystem generated it, its uniqueness domain, how it is propagated, whether transformations or retries reuse it, and whether the relevant records cover the same transaction. A label copied into a free-text field is not equivalent to a trusted transaction identifier. CTN's narrative supplies the custodian's namespace validation, but does not provide enough material to conclude that the task's registrant was a particular person or that the 08:52 recovery-method addition was made by the same actor. Those would be new hypotheses, not consequences of the join.

The course uses a claim–source–scope–discriminator record: - Claim: sync-override's observed run generated the q-144 edit. - Source: C20 scheduler run, C05 application request, C13 owner-approved state, and custodian's explicit ID-semantics check. - Scope: this request and these observed records; not every runner or possible copy. - Discriminator: a trusted contradictory namespace mapping, a mismatched application transaction, or an alternative producer record would force revision.

When a claim becomes better supported, version it; do not replace the earlier uncertainty with invented foreknowledge. The investigative record at 09:26 could not have cited C20. This discipline is consistent with the evidence-process orientation described by NIST SP 800-86. That 2006 guide supplies general forensic context, not an up-to-date vendor procedure or a legal conclusion.

7.7 Inventory deviation, operational failure and malicious intent are different classifications

An approved inventory is a versioned statement about expected configuration. An observed inventory is what a particular source returned under a particular query at a particular time. Their difference can identify unapproved or unexpected objects; it cannot by itself classify motive. An inventory may be stale, exclude contractors or emergency work, cover only one environment, or fail to include dynamically generated tasks. Conversely, an observed list may be incomplete because the responder queried only runner-03. Treat a match as evidence within its declared scope and a mismatch as a question requiring owner review.

C23 records that the owners compared sync-override and the recovery-method change against their authoritative approval sources through 09:54. That supports the case's unapproved change designation. It does not imply a named intruder, privileged insider, intentional sabotage or a single campaign. The registration at 08:47 and method addition at 08:52 make a related sequence plausible, but adjacency alone cannot link their initiators. A person could have made both, two different people could have made them, or an automation or mistaken procedure could have introduced either. The supplied cards do not discriminate those alternatives.

Use a two-track matrix before discussing eradication:

Lesson table; scroll horizontally to read all columns →

This approach avoids an attractive but unsafe shortcut: “disable svc-enroll so nothing can run.” Such an action might interrupt the approved batch-17 path, erase discrimination between suspect and healthy workflows, and exceed the specific authority supplied. Broader intervention may be appropriate with new evidence and explicit owner approval, but it cannot be smuggled into the narrower task decision.

7.8 Preservation before modification, without creating a second evidence incident

There is a practical tension: the system may continue harmful actions while the team spends time preserving proof. Solve it with a bounded preservation plan that names essential sources, protected metadata, access approvals, collection time and stop conditions. The task definition, schedule, owner metadata, run record, request-ID mapping and current inventory version each answer a different question. Preserve sufficient material to assess the unexpected task later; do not request unrelated credential secrets merely to make the package appear comprehensive.

A change receipt and a collection receipt are also different. A collection receipt records what was acquired, from which custodian/source, under what authorization, when, in what form, and how its integrity or provenance was checked. A change receipt records what was altered, target identifier, configuration revision, operator, permission and observed result. If the team writes one sentence “evidence saved and task removed,” the reviewer cannot determine whether the preservation happened before modification or whether the content matches the prior state.

A cryptographic digest can detect unintended byte differences in a preserved artifact. It cannot guarantee that the source was complete, honestly produced or semantically correct. Similarly, recording “task disabled” as a state at 10:03 is not proof that a schedule will never execute anywhere again. An adequate observation design must include the expected next trigger interval, other schedulers in scope and a method to detect re-creation. CTN only supplies a short window through 10:07; those additional checks remain future work.

Eradication has an asymmetry: confirming activity may require one trustworthy positive event, while asserting durable absence requires a defined observation window and credible coverage of the relevant sources. A four-minute non-occurrence can be entirely expected if a job runs hourly. Do not calculate “success” by dividing zero observed executions by an unspecified exposure period.

7.9 Verification contracts that can fail visibly

For each authorized change, state a falsifiable verification contract. A concise contract includes: starting hypothesis; preserved baseline; approval owner and exact target; operator and rollback; immediate positive condition; negative control proving legitimate behavior remains; observation period; independent source; and a reopen trigger. If the contract cannot be tested, revise the action plan instead of declaring success by inspection of a configuration flag.

At the 09:54 planning checkpoint, the scheduler contract remains proposed: verify that sync-override is absent from active schedules after its approved disablement; check for no expected invocation in the relevant later window; confirm the approved batch-17 S40/S41 job retains its intended function; alert on task re-creation or renewed S42 requests; and preserve the pre-change task copy. A recovery-method contract remains a separate proposed identity-owner action. Positive method removal and negative integration testing must both succeed before an identity track can be described as addressed. Because the method may affect authentication dependencies, the identity owner also must coordinate with the service owner.

At 09:59, C24 later supplies authorization to disable sync-override only. At 10:03 the application operator reports that task disabled, a read-only status agrees, and no later run is observed through 10:07. This fills some previously pending contract fields. It does not fill the recurrence check or resolve C22. The approved account remains enabled, and the book does not present a real-system disablement command. In a professional case record, the remaining fields must retain the state pending rather than being colored successful merely because the immediate status looks correct.

At 10:06 the service owner weighs the remaining legitimate S42 cost and chooses not to extend the hold beyond C21's approved 10:07 expiry. Read-only S42 monitoring and escalation on a new unexpected edit replace the temporary guard. This is an explicitly documented risk choice. It is neither a hidden extension nor a claim that task recurrence and identity access are impossible.

7.10 Correct and incorrect handoff decisions

Correct 10:07 handoff: “The preserved C20 run record and verified request semantics join sync-override to q-144. The owners classify the task and the distinct C22 recovery-method addition as unapproved changes; no supplied record identifies their author. C21 authorized the S42-only hold through 10:07. Under C24 the owners approved task-only disablement at 09:59, an operator reported it disabled at 10:03, and a status query plus short observation period supported that result. The hold was not extended after the 10:06 impact review. The identity-owner work and a complete recurrence/route assessment remain pending. Reopen/escalate immediately on an unexpected S42 write or task reappearance.” The handoff does not need an emotional label like “attacker neutralized”; it needs precise remaining work.

Incorrect 10:07 handoff: “We found the attacker at 08:47, removed persistence, revoked all access and verified the incident eradicated.” The available evidence never linked a human to registration; the recovery method remains unresolved; the narrow task disablement does not revoke the shared account; C19 covered only one route; and the observation window is too short for durable absence. A second error would be to say “we must keep the hold active indefinitely because the job was suspicious,” ignoring C21's deadline and the service owner's actual 10:06 decision.

In review, ask the author to replace each unbounded adjective—all, fully, cleared, permanent—with the source, exact scope, timestamp and check that would justify it. If those sources do not exist, record the qualified narrower claim. This is an exercise in measurable operational language, not in euphemism.

7.11 Offline laboratory: identify inventory deltas without identifying people

Objective: reproduce a scoped approval-versus-observation comparison and state two limits. Inputs: two in-memory mappings of invented job-to-request associations. Authorization and safety: disconnected Python 3; no imported logs, no production tasks and no tenant changes. Method: calculate set differences; keep the declared source coverage and task identity separate from the verdict.

approved = {"batch-17": {"q-140", "q-141"}}
observed = {
    "batch-17": {"q-140", "q-141"},
    "sync-override": {"q-144"},
}
print("C7 unexpected tasks:", sorted(set(observed) - set(approved)))
outside = set().union(*observed.values()) - set().union(*approved.values())
print("C7 outside approved:", sorted(outside))

Executed output (standard Python 3):

C7 unexpected tasks: ['sync-override']
C7 outside approved: ['q-144']

The words unexpected and outside approved are labels relative to this fixture's baseline only. The program has no human-actor fields and therefore cannot infer registration intent, credential theft or a shared actor with C22. It also cannot determine whether the task exists on a runner not represented in the input. A safe extension is to add a fictional second approved run with a source/version annotation, rerun the comparison and explain how the classification changes without rewriting the preserved original input. Changing an approved baseline after seeing a suspicious row, with no record of who approved that change, would defeat the audit purpose.

Failure injection: remove the batch-17 entry from the observed mapping. The difference then indicates a missing approved task as well as the unexpected sync-override key, but it does not tell you whether the job actually vanished or the inventory collection was incomplete. The reviewer must request coverage metadata rather than launching a corrective disablement based on the set difference. The laboratory tests reasoning over finite sets; it is not an endpoint detection rule.

7.12 Mechanism, corrective action and durable eradication are different claims

The preserved C20 scheduler record identifies a sync-override run with q-144; the application and job custodians validated the request-ID namespace against C05. C23 finds the task absent from approved inventory, and separately finds the C22 recovery-method change unapproved. Mechanism evidence supports a particular task-to-edit chain. Approval evidence establishes that an operation was permitted or not. Actor attribution would require a source tying a human or principal to registration and execution. None of these statements automatically supplies the others. The task and recovery method might be related, but timestamps 08:47 and 08:52 do not establish a shared actor.

Eradication verification has a time dimension. Reading a task's disabled flag is an immediate configuration check; seeing no run through 10:07 is a four-minute observation after C24's 10:03 report. If the task would not ordinarily run again during those four minutes, nonoccurrence has limited discrimination. A reviewer needs schedule metadata, the next expected trigger, runner inventory boundaries, source-ingestion health and a recurrence test. An unexpected re-registration or a q-144-like new S42 request must reopen the hypothesis. NIST's SP 800-61 Rev. 3 situates response, recovery and improvement in organizational risk management; this recurrence contract is original OpenCyber Academy teaching, not a NIST prescribed status test.

A second workstream must address C22's unapproved recovery-method change under identity-owner authority. Before modifying it, preserve the configuration history and safely determine whether the method is active. Removal, associated credential/session changes, permitted integration tests and independent effect checks each need a distinct receipt. Never export or publish a real recovery secret. Disabling sync-override alone cannot certify that identity access was remediated.

7.13 Compare two tempting narratives against the released facts

Bounded worked example. At 09:54 the two unapproved changes are identified and remediation is still a proposal. At 09:59 C24 supplies owners' approval to disable only sync-override after preserving the task record. At 10:03 the operator reports it disabled and a read-only status agrees. No further run appears through 10:07. The defensible result is “specified task disabled with a short observed window; identity method and task recurrence unresolved.” At 10:06 the owner considers legitimate S42 costs and does not extend the separately approved C21 hold beyond 10:07. Monitoring and a new unexpected-write trigger are assigned; they do not demonstrate that the next scheduled run was blocked.

Incorrect worked example. “An unknown task means malware, no run appeared for four minutes, and every access path was eradicated.” The conclusion converts unauthorized configuration into malicious intent, omits whether a run was scheduled in the observation period, ignores other runners and silently closes C22. It also ignores the negative control: the approved batch-17 job must remain functional after a task-specific correction. A shutdown that blocks both tasks may suppress the symptom while creating another service incident.

The approved and observed job inventories may each be partial. A set difference identifies differences in the selected source frames; the owner must compare inventory versions, collection query, active schedulers, object identifiers and observation windows. SP 800-86's forensic guidance supports treating source provenance as distinct from interpretation; its 2006 operational detail is not an endorsement of this toy comparison.

7.14 Offline C7X — fail a recurrence test with no scheduled opportunity

Objective: Test the logic separating proposal, authority, operator receipt, configuration effect, recurrence opportunity and legitimate integration. Environment: standalone Python 3 standard library, in memory; no files, credentials, scheduler actions or external connections. These flags are invented laboratory inputs, not additional CTN evidence or authentication of an approver.

def assess7(p):
    if not p["preserved"]:
        return "HOLD_BASELINE_UNVERIFIED"
    if not p["approved"]:
        return "PROPOSED_NOT_APPROVED"
    if not p["receipt"]:
        return "APPROVED_NOT_EXECUTED"
    if not p["disabled"]:
        return "EFFECT_NOT_VERIFIED"
    if not p["expected_fire"]:
        return "NO_EXPECTED_TRIGGER_TESTED"
    if p["new_run"]:
        return "TASK_STILL_EXECUTING"
    if not p["legitimate"]:
        return "BUSINESS_REGRESSION"
    return "BOUNDED_SCHEDULER_CHECK_NOT_ERADICATION"

BASE = dict(preserved=True, approved=True, receipt=True, disabled=True,
            expected_fire=True, new_run=False, legitimate=True)
CASES = [
    ("BASE", {}),
    ("MISSING_BASELINE", {"preserved": False}),
    ("NO_APPROVAL", {"approved": False}),
    ("NO_EXECUTION", {"receipt": False}),
    ("STATUS_UNKNOWN", {"disabled": None}),
    ("NO_TRIGGER_ELAPSED", {"expected_fire": False}),
    ("RECURRED", {"new_run": True}),
    ("BATCH17_DOWN", {"legitimate": False}),
]
for name, changes in CASES:
    print(name + ": " + assess7({**BASE, **changes}))

Exact tested output:

BASE: BOUNDED_SCHEDULER_CHECK_NOT_ERADICATION
MISSING_BASELINE: HOLD_BASELINE_UNVERIFIED
NO_APPROVAL: PROPOSED_NOT_APPROVED
NO_EXECUTION: APPROVED_NOT_EXECUTED
STATUS_UNKNOWN: EFFECT_NOT_VERIFIED
NO_TRIGGER_ELAPSED: NO_EXPECTED_TRIGGER_TESTED
RECURRED: TASK_STILL_EXECUTING
BATCH17_DOWN: BUSINESS_REGRESSION

Adversarial control: NO_TRIGGER_ELAPSED refuses to count a quiet period with no expected job invocation as a successful recurrence test; BATCH17_DOWN fails the legitimate-service gate even where the suspect task is reported disabled. Even BASE is only a logically consistent selected-scope exercise, never proof of complete incident eradication. A valid operational test requires verified scheduler provenance, expected fire time, and the relevant owners' authority.

Reproducible activity: Produce two separate mechanism-to-fix cards, one for scheduler task and one for identity recovery method. Each must contain source IDs, approving owner, preserved baseline, implementation status, next expected observable opportunity, negative legitimate-service test, reopen trigger and unresolved actor question. Seven-point rubric: two for maintaining the two independent paths; one each for approval/execution distinction, recurrence opportunity, legitimate negative control, exact transcript and refusal to claim durable eradication. A human-attribution claim is a critical fail.

7.15 Synthesis and handoff

At 10:07, the task-specific mechanism is better supported than at 09:26 and the task has been reported disabled; the source does not prove durable nonexecution or resolve the unexpected recovery method. C21's hold extension and C24's task action are different authorizations. The Chapter 8 identity decision, data reconciliation and recovery testing are later evidence, not available to this 10:07 handoff.

Keeping C21 and C24 separate lets a later reviewer see that extending the hold did not by itself authorize action on the task, and that each approval has its own owner and time.

Common errors and limits

• Calling sync-override an identified attacker rather than an unapproved task with a validated request link.
• Confusing a scheduler status flag with long-term absence of re-creation or alternate copies.
• Reading C22's blank actor as “anonymous attacker.” Blank means the producer did not supply attribution.
• Importing C22 into a 09:42 decision or pretending it was recovered from C08's expiring sign-in detail.
• Treating a stopped task as permission to restore S42 from an arbitrary backup. Recovery must check data and legitimate changes separately.

Practice: cause-to-fix peer review

One learner submits a cause-to-fix contract at 09:54. Another marks each line observed, proposed, approved, executed or verified and asks for an alternative explanation of the recovery-method change. Then reveal C24 and revise the contract: which tests have results, which are pending and what evidence must be preserved? Run the in-memory manifest comparison only on the supplied values. The next subject uses the residual risk and changed service state to design recovery.

Exercises — subject 7

EX031 — Mechanism versus actor. Inputs: C05, C12, C14 and C20. Write a three-column claim ledger: supported mechanism, weakened interpretation and actor statement that remains forbidden. A 2-point result names the validated q-144 link without joining it to s-77 or a human.

EX032 — Two-path eradication contract. Inputs: C20–C23. Produce separate task and recovery-method rows with baseline, proposed change, approval owner, positive/negative test, monitoring and reopen trigger. A 2-point result leaves unexecuted changes pending and preserves configuration evidence.

EX033 — Time-bounded hold review. Inputs: C16–C21 and C24. Build a timeline of initial hold approval, extension approval, execution, 10:06 review and 10:07 expiry. State the residual risk after expiry. A 2-point result does not stretch C17 or C21 beyond their approved scope.

EX034 — Manifest fixture. Run or hand-compute the Python fixture in §7.5; give the two exact output lists and two limits of the conclusion. A 2-point result does not classify intent or all runners from this two-run comparison. Reproduce the C7 inventory-delta output in §7.11 and state a coverage limitation independent of actor attribution.

EX035 — 10:07 eradication handoff. Inputs: C20–C24. Write a 120–180-word handoff with what was preserved, approved, executed and verified, what still needs identity-owner action, and a stop condition. A 2-point result avoids a “fully eradicated” or “case closed” claim.

Subject synthesis

C20 directly links a nonbaseline task to the S42 edit, and C24 reports that this task was disabled. The short observation window, C22 recovery-method change and unknown actor keep eradication open. Chapter 8 must restore the correct slot state, protect legitimate S40/S41 changes and test service behavior without confusing a backup copy with an accepted return to service.