# Module 9 practice · investigate before changing a component

Use [the lesson](../lessons/09-trace-failures-and-state-limits.md) and compare [the separate solutions](../solutions/09-failures.md).

**A. Reproduce the trace.** Run `methods.py failures`. Identify the successful retrieval, the budget loss, the final template reason and the separate changed-source reason. Explain why this demonstrates neither a failed retriever nor neural prompt-injection resistance.

**B. Classify four failures.** For each, name the earliest relevant stage and a local synthetic check: an archived schedule appears; a six-word chunk omits a distant exception; a paraphrase returns no candidates; a complete packet produces a claim about laptops. Do not change production data or use a real learner account.

**C. Propose a small counterfactual.** Keep the renewal query and ranked IDs fixed. Describe the single change that tests the budget-loss hypothesis. What result would support the hypothesis, and what result would require a different explanation? Explain why adding more candidates alone is not a direct test.

**D. Write a handoff.** In at most six sentences, state what the local system implements, two observed failures, what has been tested and what remains unverified. Include the difference between a fingerprint check and source truth, and state that source instructions do not authorize account actions.

Self-review: stage-specific reasoning, unchanged unaffected components, exact executed mechanisms and a readiness statement that cannot be mistaken for a production or learner-pilot claim.