A parks computer-vision project has no documented input/output specifications for each lifecycle phase. What should the auditor recommend?
Select an answer to reveal the explanation.
Short Explanation
If nobody wrote what goes in and what comes out at each phase, the vision project will play telephone. Spec the inputs and outputs for design, build, and operate. Annotation rules for training data alone won't give you that.
Full Explanation
Documenting input and output specifications for design, build, and operate phases of a parks computer-vision solution works because I/O contracts define what images, labels, scores, and alerts the system may consume and emit at each lifecycle stage. Clear specs enable acceptance tests, interface agreements with cameras and work-order systems, and operational troubleshooting when detections drift. Undocumented informal inputs invite silent schema changes, mismatched label taxonomies, and untestable behavior. The correct recommendation is phase-appropriate I/O specification discipline for municipal computer vision.
Maintaining detailed versioned records of model architectures and training datasets for build phase reproducibility assessments fails because it addresses only build-phase reproducibility and does not establish the input/output contracts needed across design, build, and operate phases. Defining inference latency thresholds and camera availability targets for operate phase service level monitoring fails because service-level targets are not input/output specifications and leave the design and build phases without documented data contracts. Standardizing image resolution and annotation guidelines for training datasets across model development iterations fails because it covers only training-data conventions and does not document the inputs and outputs the system consumes and emits at each lifecycle stage.
Exam caveat: overly rigid specs that never version can also stall needed sensor upgrades; I/O documents should be versioned artifacts under change control, not frozen once and forgotten. Operational check: publish design/build/operate I/O specs with schemas and examples, link them to test cases, and require pipeline changes that alter inputs or outputs to update the specification and re-run contract tests before promotion.