Find the boundary where valid engineering meaning is lost instead of treating every report discrepancy as a hardware fault.
What you will learn
- Trace report rows to original payloads, schema, units, run identifiers, timestamps, and processing revision.
- Separate symptoms, hypotheses, and evidence; propose checks that discriminate between explanations.
- Reduce a false pass to a minimal reproducer across the decoder and reporting boundaries.
- Preserve invalid status, compare before and after under the same conditions, and rerun unaffected controls.
Practice focus
Investigate an incomplete frame whose missing measurement is replaced with zero by reporting code. Correct that reporting boundary without changing the decoder, source data, scale, or thresholds.
Engineering deliverable
A traceable debugging record: reproducer, localized defect, reviewed correction, and before/after evidence.
Lesson transcript
Scene 01
An analysis report can show PASS even when its input contains no valid measurement. The defect may be in the reporting path, not the hardware. This refresher uses GitHub Copilot to investigate a reproducible discrepancy, preserve traceability to the source data, and verify a focused correction.
Scene 02
Start with the input file, not the summary. Check the schema, units, run identifiers, timestamps, and processing revision. Trace the suspect row back to its original payload, and retain the original file unchanged. When comparing runs, align matching records and confirm comparable settings. A difference in report values is not evidence of a physical change until those conditions are controlled.
Scene 03
Give Copilot the relevant code, minimal input, command, expected behavior, and available failure evidence. Ask for competing explanations and a discriminating check before editing. In our example, validity could be lost during decoding, during report generation, or through stale output. Keep each explanation as a hypothesis until a reproducible check locates the defect.
Scene 04
Reduce the discrepancy to one frame and two function boundaries. The decoder correctly returns INVALID without a measurement. In the authored reporting code, a fallback replaces that missing value with zero, then applies the acceptance limit. This explains the false pass without changing the decoder. It does not explain why the frame was incomplete, which remains a separate investigation.
Scene 05
Once the faulty boundary is identified, request a localized correction. Preserve the invalid status instead of manufacturing a measurement. Do not change the decoder, scale, thresholds, or source data. Review the diff for unrelated edits. Keep this input as a regression case so the same loss of validity can be detected again.
Scene 06
Run the reproducer before and after the patch under the same input and configuration, then rerun existing checks. If Copilot is permitted to execute the specified command, review its actual output; otherwise, run it yourself. Record both revisions, warnings, and failures. If no execution took place, describe the patch as unverified.
Scene 07
Compare the failing row and unaffected controls, not just the report total. Invalid input must remain invalid; a valid zero must remain a measurement. Positive, negative, and out-of-range values should retain their approved classifications. The table shows reference expectations, not recorded passes. Do not change acceptance values to make the correction appear successful.
Scene 08
Close the investigation with the source reference, reproducible case, localized defect, reviewed change, and recorded checks. State what remains unresolved. Copilot can help organize the investigation, but the conclusion must stay within the evidence: correcting a reporting defect does not establish that the hardware is healthy.