Verification is useful when its claims are as precise as its checks. In this lesson, we will turn your test and replay results into a concise evidence report. We will also identify the physical questions those results do not answer. Start with the actual checkpoint-seven receipts from the previous lessons. You do not need a board to complete the core report.

A host assertion checks software behavior for controlled cases. A replay runs synthetic events through the adapter, shared policy, and output path. A firmware cross-build checks source against a selected target and toolchain. These are three useful forms of evidence, but they establish different things. Combining them into a vague statement that the sensor works loses the distinctions an engineer needs.

Open one actual test record. Identify the source or checkpoint, command, input conditions, process result, and relevant assertions. A statement such as the stale-boundary test rejected the seeded comparison is supported when the record shows the compiling wrong source and the behavioral failure. A final passing line by itself does not establish the mutation part of that claim.

Now open a replay record. The inputs are explicitly synthetic. The program executes real software logic, but the temperatures did not come from a physical sensor. The injected timestamps are controlled inputs rather than measured device timing. This is a strong way to reproduce a software sequence, provided the result remains labeled according to its actual origin.

Consider the firmware-build receipt. It needs the source identity and the selected target inputs as well as the command result. A successful cross-build establishes that the source compiled and linked under those conditions. It does not establish that the program was uploaded, that USB enumeration worked, or that a physical device behaved correctly after startup.

Use three columns in your report: claim, evidence, and limitation. The claim should be a complete statement. The evidence should point to a real record. The limitation should identify what a reader might otherwise infer incorrectly. For example, shared-policy host tests support behavior for their cases, while electrical faults and sensor accuracy remain outside their scope.

Be careful with the word fault. In the program, fault is a state that can be the correct response to missing, nonfinite, or stale input. A valid replay fixture can intentionally reach that state and still exit successfully. The program did its job by reporting the condition. Treating every fault state as a broken test would encourage you to remove the very cases that demonstrate useful error handling.

A malformed fixture is different. If its numeric token or row structure violates the input grammar, the parser rejects the file with a line-number diagnostic and exit two. A failed assertion is another distinct result, reported by the test executable with exit one. The report should say which outcome occurred instead of using one undifferentiated word for all of them.

Look at the supplied overclaim: replay passed, so the board is verified. Correct it by naming the actual result. State that the recorded synthetic replay matched the expected software behavior for the checked source and inputs, if that is what the evidence shows. Then list the physical checks that were not performed. This correction preserves the useful success while removing an unsupported inference.

An optional physical-check list can be prepared without pretending it happened. It may include exact board and breakout revision, acquisition-adapter initialization, missing-sensor behavior, upload and serial operation, recovery, timing, and an appropriate measurement method. Mark those items as unperformed unless actual separate evidence exists. The core course does not require them to be completed.

Do not confuse a manufacturer document with a bench result. A source can establish a board feature or a documented interface, but it does not show the jumper position or wiring of an unobserved unit. Likewise, a plausible temperature is not a calibration result. Each claim needs a procedure suited to the question it asks.

Review source identity before reusing a passing receipt. An old result can remain accurate history while failing to certify a later edit. Record what changed after the check and decide which verification is still relevant. A wording-only correction may leave policy results unaffected, while a changed comparison requires repeating the behavior cases that depend on it.

Your exercise is to write three supported software claims and three unperformed physical claims with their missing evidence. Correct the replay-to-board overclaim and explain the difference between policy fault, fixture parsing failure, and assertion failure. Submit the report with accessible receipts. Do not create invented physical data to make every row look complete.

State the caller contract when it affects a claim. The snapshot accessor reports stored policy state; time-dependent freshness must be updated through polling or acquisition before inspection. A test that skips that required step may ask a different question from the documented behavior. Include such preconditions in the requirement-to-check map rather than hiding them in an implementation detail.

If a receipt is missing, say that the claim is not established by the available record. You can rerun a relevant check when the environment is available, but label that as a new result. A reconstructed present check does not recreate an earlier unrecorded run. This distinction matters when a handoff or release note has carried a confident but unsupported statement forward.

Pause here to complete the report. A reviewer should be able to select any claim and identify the evidence that supports it, the source it applies to, and the important limits. The report should remain readable without tiny screenshot text. Screenshots illustrate genuine results, while the written commands and interpretation keep the procedure searchable and reproducible.

Finish by explaining the shared-source diagram in one sentence of your own. The same policy implementation is exercised through host and firmware build paths, while physical acquisition remains a separately validated extension. Honest scope is part of the engineering result. You now have a verification report that supports the next task without asking another person to trust a label that says everything passed.