---
id: M07-L03
title: "State what your tests actually prove"
module: M07
chapters: "15"
checkpoint: "CP07"
---

# M07-L03 — State what your tests actually prove

Write a verification report whose claims match its evidence. Start with your CP07 test and replay records. The output is a concise claim/evidence/limitation table, including a separate optional physical-validation list.

A host assertion checks software behavior for controlled cases. Replay exercises the adapter, shared policy, and output with synthetic events. Cross-compilation checks the source against a selected target/toolchain. These activities provide useful evidence, but none establishes wiring, sensor accuracy, USB enumeration, successful upload, or physical timing.

Use precise labels: `host-test`, `synthetic`, and `firmware-compile`. Reserve `board-observed` for actual physical evidence and identify human-reported observations separately. A copied screenshot or a confident agent summary does not transform the category.

Review three proposed claims. “The stale-boundary assertion rejected the seeded comparison” needs the failing test and diff. “The firmware compiled for the recorded target” needs the build command/result and source identity. “The sensor is accurate” needs an entirely different measurement procedure and evidence absent from the core course.

Distinguish policy state from process failure. An intentional missing or nonfinite sample can produce FAULT during a successful replay. A malformed fixture is rejected with a parsing diagnostic. The test runner reports assertion failures separately. Combining all three into “it failed” hides the next useful action.

Create an optional physical-check list without marking it performed: exact board/revision, acquisition adapter, initialization/error behavior, upload/serial, recovery, timing, and measurement method where appropriate. Physical equipment remains optional; honest limitations do not reduce the agreed core software result.

Finish by checking source identity. A result from an earlier revision may remain valid history but cannot automatically certify a later edit. Link the record to the checked source, note relevant subsequent changes, and rerun only the checks justified by those changes.

## Resources and completion

Read Chapter 15 and the matching Sensor Monitor checkpoint README, requirements, and evidence notes. Project paths are relative to its root. Figures: SS15-05, D12. Attempt the [exercise](exercise.md), preserve actual results, then use the separate instructor answer key. 

Source resources: [Chapter 15](../../../../book/chapters/ch15/chapter.md); [checkpoint and recovery map](../../../../examples/sensor-monitor/docs/checkpoints.md). Use the README and requirements inside your named checkpoint; the repository's final CP09 files include features absent from earlier stages. View [D12](../d12.svg) with its [accessible description](../d12.md).