The final challenge is to demonstrate and defend your result. You have built a documented sensor-monitor workflow with source control, project context, skills, tests, replay, and a capstone feature. Now you will connect those artifacts to the evidence that supports them. The core outcome is a complete private candidate with reproducible software checks, not a public launch or a physical kit demonstration.

Begin with the source identity and the requirement. Show the current candidate and explain what changed from checkpoint eight. The capstone adds configurable alert behavior and bounded commands while preserving missing, nonfinite, stale, and recovery handling. A reviewer should be able to understand the result without reading the entire conversation that produced it.

Present the changes as a small sequence of engineering decisions. Explain the policy and configuration slice, the parser, the host and firmware integration, and the verification/documentation work. Point to coherent commits or a reviewed diff. A large amount of generated source is not evidence of quality by itself; the relationship between the requirement and the final behavior matters.

Defend the hysteresis rule with a concrete case. Twenty-seven point five degrees can be normal or alert because the prior non-fault state determines retention inside the band. At twenty-eight, normal enters alert. At twenty-seven, alert clears. Show which tests establish those equality and history conditions. A statement that alerts work is too broad without those details.

Explain recovery next. Startup and fault both need two consecutive fresh valid samples. An invalid reading or stale gap resets the count. A valid threshold command cannot clear fault because it changes configuration rather than supplying a sample. After recovery, the state is classified from fresh input and the entry threshold, not an old remembered alert.

Show the command contract and its tests. The complete bounded line must match the promised grammar. Trailing numeric text, out-of-range values, oversized input, and truncation are rejected without changing the prior setting. Reset restores the default threshold because settings are RAM-only. These are observable requirements, not optional implementation details hidden behind a successful command example.

Present actual host and replay receipts. Name the source, input, command, result, and interpretation. Distinguish an expected fault state during valid replay from a malformed fixture and an assertion failure. Keep synthetic labels visible. A reader should not have to infer whether temperatures were measured or supplied by a fixture.

Show the meaningful defect-rejection evidence. The bad hysteresis and command variants should compile and then fail the relevant behavioral checks. Preserve the good solution's passing result as well. This demonstrates specific defects the verification can detect. It does not prove the absence of every possible bug, and an assertion count should not be presented as that guarantee.

Add the firmware-build receipt and the fresh-checkout reproduction. The build supports compatibility with the recorded target inputs. The second checkout tests whether the distributed source and written setup are sufficient without untracked local files. A clean status alone does not establish reproduction; the required commands must actually run in the fresh copy.

Now apply the one-hundred-point rubric. Requirements and sourced hardware facts receive fifteen points. Git history and review receive fifteen. Firmware behavior receives twenty-five. Verification quality receives twenty-five. Documentation and handoff receive ten, and project instructions and skills receive ten. Score using linked artifacts rather than how polished the presentation feels.

The suggested target is eighty, with mandatory gates that a high score cannot replace. The build must reproduce. Critical software behavior must meet the requirements. Host and replay checks must have actual results. Evidence labels must be honest. If one of those gates is open, name the missing evidence and next action instead of averaging the problem away with points from other categories.

Include the actual fresh-session and skill records. Project instructions should have guided a bounded task, and the skills should have been evaluated on relevant, clean or unrelated, and incomplete-input cases as appropriate. A valid skill file or a summary of instructions is not a behavior result. If selection was unobservable, preserve that uncertainty separately from the quality of the output.

State the physical boundary plainly. No board measurement, wiring result, upload, sensor accuracy, USB behavior, or physical timing follows from the core software checks. Optional physical work has separate procedures and evidence. It is not required for the agreed core score, and it must not be implied by a screenshot of passing tests.

Prepare for one challenge to your evidence. A reviewer might ask whether a passing result belongs to the current source, whether the second checkout actually ran, or whether a failed mutation was only a compiler typo. Answer by opening the relevant receipt and explaining its scope. If the record cannot answer, preserve the gap and perform the missing check instead of treating the question as a presentation problem.

Finish the presentation with your transfer task and maintenance plan. Explain one observation about total effort, including review and repair. Name a realistic trigger for rechecking a tool, source, or skill and the check you would use. The workflow should remain useful after the course because you know how to maintain its assumptions and evidence, not because you collected a fixed set of prompts.

Your submission is the complete candidate bundle, scored rubric with evidence links, transfer result, maintenance plan, and a concise defense of these engineering decisions. If a result cannot be reproduced, preserve the failure and return to the relevant bounded repair. Do not defend a passing claim that the available evidence no longer supports.

Pause here to complete the challenge and final module quiz. Four correct answers out of five is the recommended quiz target, with unlimited retry and explanations. Quiz progress is a self-check; practical completion depends on the artifacts and mandatory gates. When those are satisfied, you have demonstrated a repeatable way to use AI in embedded engineering while keeping the source, decisions, and evidence understandable to the next person who must rely on the work.