Outcome: Separate a grounded claim, a proposed tool action, and an observed result.
Start: M01-L02 and its saved context comparison.
A source supports a claim only when it actually contains the relevant information and applies to the exact object under discussion. A part family name, search snippet, or plausible citation is insufficient for a consequential board decision. Open the primary document, identify the variant and revision, and inspect the relevant sentence or table. Keep the claim and supporting location together.
Retrieval can bring additional material into context, while tools can read files or execute commands. Neither guarantees that the final interpretation is correct. A command shown in chat is a proposal; a tool result is an observation with an execution context. A compiler result supports a build claim for the source and options used. It does not establish physical operation. OpenAI tool use
Work through this original sample answer: “The fixture is invalid, so BenchNote outputs FAULT. Three successful readings clear the fault. Run the tests; they will pass.” The first claim is supported by the Chapter 2 passage. The second invents a recovery count. The final sentence proposes an action and predicts its result; it is not an executed test.
Revise it to preserve the supported rule, state that recovery is unspecified, and name a concrete check without claiming execution. This is a useful engineering answer even though it contains an unknown. It points to the missing requirement and avoids making the test report say more than occurred.
In your notebook, use separate fields for documented, inferred, tested, and unresolved. A hypothesis can be useful without being called a root cause. Record what observation would distinguish it from another explanation. This habit becomes central to debugging later.
D03. The current request, selected history, relevant references, and actual tool results enter bounded context. The generated answer still needs verification.
Practice and completion
Complete the exercise, then compare your artifact with the separately distributed instructor answer. A lesson acknowledgment records your own progress; it does not certify that a physical test occurred.
Chapter 2. Resources: Original BenchNote note and original reference responses. Figure references: SS02-02–03; D03.
Recording transcript
In the previous lesson, a short reference passage made an answer easier to check. Now we will look more closely at sources, tools, and uncertainty. The goal is to preserve useful information while identifying what the available evidence cannot establish. This skill matters when an answer combines a correct rule with a convincing invented detail.
Open your context comparison and find the statement about invalid input. The fictional BenchNote note says an invalid sample produces FAULT and its numeric temperature must not select the ordinary states. That is a grounded claim because we can point to the governing sentence. The answer does not become stronger merely by adding a longer explanation after it.
Now read the original sample answer supplied for this lesson. It says the invalid fixture produces FAULT, three successful readings clear the fault, and running the tests will produce a pass. This sample was written for instruction. It is not a transcript of a model run. We will inspect each sentence independently rather than accept or reject the paragraph as a whole.
The first statement matches the note. Keep it. The second statement supplies a recovery count that the note never defines. Three might be a reasonable design choice in some system, but it is not a fact about this exercise. Mark it unresolved and ask for the intended recovery requirement. That leaves a small, actionable question instead of hiding a decision inside an explanation.
The third statement contains two different things. Run the tests is a proposed action. They will pass is a predicted result. Neither is evidence that a command actually executed. A terminal result would need the command, its working directory, the source version, the input, and the observed outcome. The same word PASS can appear in an illustrative answer and a real test log, so provenance matters.
This is why we inspect action records in an agent interface. A model can generate text. An agent may also use permitted tools. The tool result tells us more about what occurred, but we still need to interpret its scope. A successful compiler invocation in the wrong folder does not establish that the intended change builds. A test executable left over from an earlier source version can create a similarly misleading impression.
Use a short evidence record rather than a long narrative. Name the source or command, state what it supports, and note the remaining limitation. For example, the supplied note documents the fault rule. A host test can check the implemented rule for controlled input. A firmware cross-build checks compilation for the selected target. A physical measurement requires an actual physical setup and observation.
Sources need scrutiny too. A link is not enough if it points to the wrong board variant or an unrelated section. Open the primary document and identify the exact part, revision when available, and the relevant sentence or table. A search result can help you locate a document, but its short snippet may omit conditions, units, or exceptions that change the meaning.
Consider a pin claim. The assistant recognizes a board family and supplies a familiar number. Your next action is to inspect the exact board pinout or schematic. Record where the value appears and which variant it describes. Do not take two assistants repeating the same number as equivalent to a checked primary reference. They may share the same mistaken association.
A retrieved document can improve freshness, but retrieval is not automatic verification. The assistant might find the right manual and read the wrong column. It might confuse a typical value with a guaranteed limit. You still need to connect the claim to its conditions. Later we will practice this in a constraints table, where values, units, sources, and unknowns stay together.
Return to the sample answer and add a physical claim: the sensor cable is disconnected. Our input was a deliberately authored synthetic tuple. It cannot establish the state of a cable. Even an invalid physical reading would not uniquely identify that cause without another check. A disconnected cable, failed conversion, wrong configuration, or deliberate fault injection might lead to similar software symptoms.
A useful hypothesis names what would distinguish it from alternatives. For a software exercise, inspect the validity field and the parser result. For optional bench work, choose an appropriate observation of the actual interface. Do not call a hypothesis the root cause until evidence supports that decision. This keeps debugging from becoming a series of guessed edits that conceal the original symptom.
Now rewrite the answer. Preserve the supported FAULT rule. State that recovery is unspecified in the introductory note. Propose checking the implemented policy after its requirement is defined. Label the input synthetic and avoid the cable conclusion. The corrected answer can be shorter than the original while carrying more reliable information.
In your exercise table, use separate fields for documented, inferred, tested, and unresolved. These labels can change as evidence arrives. A document-dependent value can become documented after inspection. A proposed command can become an executed check after a real run. An unresolved physical claim remains unresolved if no physical observation occurs, even when all software checks pass.
Before finishing, ask whether another person could follow your next action without guessing. Locate the recovery requirement is clear. Verify everything is not. Run the named host test from the recorded project root is clear. Make sure it works is not. Concrete checks turn uncertainty into work you can schedule and review.
When you save a source reference, include enough detail to relocate the evidence. A title and section are more helpful than a bare link to a large manual. For a table, keep units and conditions with the value. If the page changes later, your record explains what proposition you relied on and when you checked it. That makes maintenance a focused comparison instead of another open-ended search for something that sounds familiar.
Complete the short revised answer and keep it with the source/check table. You are ready for the next lesson when you can explain which statement is supported, which is invented, which is proposed, and which would need a new observation. We will use those distinctions to write a task brief whose success is visible from the beginning.
Download transcript
