---
id: M04-L04
title: "Record decisions and test evidence"
module: M04
chapters: "9"
checkpoint: CP02
---

# M04-L04 — Record decisions and test evidence

Produce a decision record and a result record that cannot be confused with each other. Start with the linked CP02 documents. You will define an expected check, inspect actual evidence when available, and write a concise handoff.

A decision records context, choice, alternatives considered, and consequence. For Sensor Monitor, using host replay as the required core demonstration supports reproducible software learning without physical equipment. Its consequence is that replay cannot establish electrical behavior, sensor accuracy, or MCU timing. This remains true even when every host test passes.

A test plan states a procedure and expected outcomes. Derive the outcomes from requirements before inspecting the implementation. For an inclusive threshold requirement, equality belongs in the planned cases. For startup behavior, read the checkpoint's applicable requirements rather than importing later capstone features into an earlier exercise.

A result records what actually happened: source/checkpoint identity, environment, command, input source, exit result, relevant output, and interpretation. Name a fixture only when the stage actually reads one. The evidence document can link to a saved log rather than reproducing every line. Keep a failed attempt when it explains the defect and recovery. Historical evidence needs clear scope so it cannot be mistaken for the current result.

CP02 prints one fixed synthetic reading and does not yet parse fixtures. Plan a check of that line and its synthetic label. Use the maintained wrapper from the project root:

```powershell
.\scripts\replay.cmd
```

Read the output and process result. If the check cannot run, preserve that limitation. “Tests should pass” is a prediction; “tests passed” needs an accessible receipt. A confident agent sentence is not an independent record of execution.

For the worked exercise, classify four statements: the monitor must follow a specified boundary; the selected board has a documented memory variant; the future capstone plans RAM-only configuration; a named fixture produced a particular output during an actual run. The first is a requirement, the second a sourced fact, the third a decision, and the fourth a result whose receipt must be inspectable.

Finish with a handoff naming the current state, reviewed changes, last relevant checks, open questions, and one bounded next action. Do not paste the whole conversation. A new session needs the active evidence and the next uncertainty, not every abandoned idea. Arbitrary Markdown files may need explicit links or a prompt reference before an agent reads them.

## Resources and completion

Use the Sensor Monitor `CP02` download and its `README.md`; project paths in this lesson are relative to that root. Read Chapter 9 for the full lab and explanatory review answers. Figure IDs: SS09-03, D08. Primary references: [Adafruit product 5477](https://www.adafruit.com/product/5477) and [GitHub Markdown tables](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables). Complete the [exercise](exercise.md), preserve actual evidence, and use the separate instructor answer key for self-check after attempting the task. Narration scripts are production sources; final transcripts must match the actual narrated edit.