A county's ML pipeline occasionally fails in production because malformed input data reaches the training job partway through a run, wasting compute time before the failure surfaces. The team wants automated checks that catch schema problems before a training job ever launches. Which pipeline design addresses this?

A schema-validation stage placed before the training step inspects incoming data against expected structure and types, and if it finds a mismatch, it halts the pipeline right there — before any training compute is spent — which directly targets the wasted-compute problem the county is experiencing. Relying on the training script's own exception handling means the failure is only caught after training has already started, which is precisely the late, expensive failure the team wants to eliminate, not just handle more gracefully. A manual eyeball review doesn't scale reliably and can miss subtle schema issues (a wrong data type, a missing column, an unexpected null) that aren't obvious from a quick visual scan, especially across large files. Increasing compute size treats the symptom (a slow, wasted run) rather than the cause (malformed data reaching training at all), so it burns more resources on the same doomed run instead of preventing it. Scope caveat: schema validation should be versioned alongside the pipeline itself, since a legitimate change to the input data's structure requires the validation rule to be updated too, or valid data will start failing the check. Operational check: intentionally submit a file with a missing or mistyped column and confirm the pipeline halts at the validation stage rather than proceeding to the training job.