This challenge asks you to rescue a vague request using the three habits we have practiced. You will identify what the evidence supports, supply useful context, and write a bounded engineering brief. The result is a small evidence packet that another person can inspect. You do not need physical hardware or an uninterrupted AI account to complete the reasoning work.

Read the supplied request carefully. It says the sensor is unreliable, asks you to make the readings accurate, permits any change, and demands a statement that it works. The only evidence is an authored synthetic log with validity flags and temperatures. The request has already jumped from software input to a physical diagnosis. Our first task is to separate that assumption from what we actually know.

Open the Chapter 3 original reporting fixture. Identify its file name and the meaning of its fields. Count the records and locate any invalid sample. Record the input's origin as synthetic. A temperature number in this file is a controlled value chosen for a software exercise. It is not a measurement of the room, and it cannot establish whether a sensor is calibrated.

Now identify a problem the available material can support. Perhaps the explanatory report hides the validity flag or fails to identify synthetic origin. Those are concrete reporting problems. We can improve the explanation while preserving the underlying numbers and policy. We do not need to replace hardware, invent a communication fault, or change the warning threshold to make the task useful.

Write the goal in one sentence. For example, make the report clearly distinguish valid and invalid synthetic records. Write the current behavior in a separate sentence. This prevents the brief from treating a broad accusation such as unreliable as if it were an observed technical condition. Your revised task should be understandable without the original emotional context of a frustrating debugging session.

Name the Chapter Three resource version and actual fixture. Include the relevant small input, or point to the file if the selected interface can inspect it. Preserve the original. If you shorten the input for discussion, state which records you selected and whether any values changed. A reviewer should be able to return to the source and check your interpretation.

Set the boundaries. Preserve temperatures, validity flags, state names, record order, and existing policy. Do not edit firmware, dependencies, timing, or the fixture. Request one artifact, such as a proposed report format with two illustrative lines and a short verification plan. This turns the task from an open-ended rewrite into a decision you can review in one sitting.

Define acceptance before looking at the response. The report must identify synthetic origin, retain invalid status, preserve original facts, and avoid a physical accuracy claim. It must distinguish proposed checks from executed results. Add a negative case so that an invalid record containing a plausible number cannot pass unnoticed as a valid reading.

If you use a live assistant, save the actual answer. If service access is unavailable, analyze the original challenge response provided in the lesson. That response is deliberately mixed: it proposes useful synthetic labels, suggests raising the threshold to suppress warnings, and promises to report calibration. It was written for instruction, so do not call it an observed model failure.

Review each idea separately. The synthetic label serves the task and may be accepted if it preserves the data. Raising the threshold changes policy and lacks support from the brief. It might hide an inconvenient warning without addressing the reporting problem. The calibration statement requires physical evidence that we do not have. Reject those two proposals with reasons tied to the task and evidence.

A good review is actionable. Instead of saying the answer is bad, say keep the origin label, remove the threshold change, and replace the calibration claim with an explicit limitation. Then name the next check: compare the proposed report against the original records and confirm that validity and values are preserved. This gives the author or assistant a clear correction to make.

Your evidence table should contain at least five rows. Include a supported input fact, a documented rule from the original note, an unresolved requirement if one matters, a proposed action, and a physical claim that the input cannot establish. The point is not to fill categories mechanically. It is to make the current status of each consequential statement visible.

Consider what happens if the assistant answers correctly the first time. You still complete the review. Identify why the result satisfies each criterion and state what it does not establish. Success does not require catching an error. It requires a method that would catch a meaningful error if one appeared. The supplied mixed response lets everyone practice that part of the method.

Consider the opposite result: the assistant ignores your constraints. Preserve the response and restart from the unchanged input with a narrower task. You may ask for a plan before edits if the boundary remains unclear. Do not keep escalating the wording while allowing unrelated changes to accumulate. The recovery should leave a known baseline and a smaller, more checkable request.

Before submission, inspect the packet as if you were another maker. Can you find the input? Can you tell what was requested? Does the review explain which changes are accepted and rejected? Can you distinguish an illustrative output line from a real command result? Are physical unknowns still visible? Correct any gap that would force the next person to guess.

Keep the corrected artifact separate from your critique. A review note explaining three problems is useful, but the next person also needs the actual report or brief they should use. Read that final artifact on its own once more. It should not require the reader to mentally undo rejected suggestions or remember qualifications hidden in an earlier paragraph. The result of review is a coherent usable document, with its remaining unknowns stated where they matter.

Finish the module quiz after the challenge. The questions check the same practical distinctions: model versus agent, context versus permanent knowledge, source support, synthetic evidence, and bounded scope. A passing score is a self-check, not a certificate that hardware has been tested. Keep your packet, because the next module will give these artifacts a concrete project folder, toolchain, and version history.