A water utility diagrams governable stages for a leak-prediction project. Which sequence correctly reflects a typical AI project life cycle?
Select an answer to reveal the explanation.
Short Explanation
Building a leak predictor is like fixing a leaky house: name the problem, gather good data, train carefully, test before you trust it, then watch it after it goes live. Skipping the early frames or the validation step is how governance headaches start.
Full Explanation
A water utility diagramming governable stages for a leak-prediction project should follow a typical AI project life cycle: problem framing, data preparation, training, validation, deployment, and monitoring. That sequence keeps purpose, data fitness, model quality, release discipline, and post-go-live oversight visible to utility leadership and regulators.
Why the other options fail by concept: Deploying first and inventing the problem statement after residents complain inverts accountable design and invites solving the wrong leak problem. Monitoring-only approaches that treat training and validation as optional skip the evidence needed before trusting predictions that drive crew dispatch. Buying hardware, skipping data work, and treating validation as a post-incident activity prioritizes capital spend over data quality and safety gates.
Exam caveat: Life cycles are iterative—monitoring findings often return you to data prep or retraining—but skipping framing or validation is not “agile,” it is unmanaged risk. Utilities must also align stages with change-management and safety procedures for field work triggered by model outputs.
Operational check: Gate the leak-prediction project with written exit criteria per stage (problem metrics, data lineage and quality reports, training config, validation results vs. baseline, deployment runbook, monitoring SLOs). Do not promote to production without validation evidence and a monitoring owner on the utility org chart.