Academic case · Python automation
Green checks.
An incomplete inventory.
The code ran against the systems it knew about. Discovery had missed part of the environment.
My Python automation assessments came back for revision even though the submitted code passed its local checks. The checks were not lying about the systems they covered. They were incomplete in the same way the implementation was.
The repair started with a more basic question: what proves that the inventory includes everything the workflow is supposed to cover?
- My part
- Implementation, diagnosis, remediation and evidence rebuild
- Recorded outcome
- Corrected and resubmitted on September 4, 2026; no final grade claimed
Where the checks fell short
The device inventory included statically addressed systems but skipped systems whose addresses were assigned dynamically. The workflow could behave correctly on every discovered device and still leave part of its required scope untouched.
That discovery gap produced several downstream findings. A service-status check also had incomplete coverage, and the evidence screenshots lacked required timestamps. These were different defects, but repairing returned rows independently would have missed the shared inventory problem.
Repairing the cause
- Make discovery part of the acceptance test
- I expanded discovery to include both addressing modes. The population supplied to the workflow needed verification of its own, rather than being treated as a trustworthy setup detail.
- Check the full service scope
- I added the missing service-status check and reran the workflow against the corrected inventory. Fixing discovery alone would not repair a separate omission in what the workflow checked.
- Rebuild evidence to its actual requirements
- I rebuilt the evidence with timestamps so it could establish when the observed state existed. A screenshot of the right state was insufficient if it did not meet the evidence contract.
What changed
The corrected implementation and evidence were resubmitted. The more useful result for my practice was a better verification model: the implementation's own inventory cannot also be the only authority for whether coverage is complete.
A separate source of truth should establish the expected population. The comparison is between what should exist and what discovery found, not merely between what the code received and what it reported processing.
A workflow cannot cover systems it never discovers.
The case makes a useful test for confidence in a green result. If the test and implementation inherit the same bad assumption, agreement between them is not enough.
Scope and outcome
This was academic automation work, not a paid client engagement. The record used for this case ends at correction and resubmission on September 4, 2026. This page does not claim a final assessment result.
Assessment prompts, source solutions, system addresses, screenshots and evaluator details are not published here. The case explains the failure mechanism and remediation, rather than offering an assessment solution or claiming a measured commercial outcome.