While cleansing and structuring the gate-scheduling dataset during Data Preparation, Meridian's engineers realize that a full third of historical gate-assignment records are missing the connecting-flight linkage field entirely — a field the original Data Understanding review had assumed was consistently populated. What should the project team do?

Determining when to iterate back to a previous phase applies just as much when a Data Preparation activity uncovers a problem as when Data Understanding itself does — discovering that a third of records lack a field the project assumed was reliably populated is new information that should trigger revisiting the Data Understanding assessment for this specific use case (connecting-flight-aware scheduling), before continuing to sink preparation effort into a dataset that may not actually support the goal. Imputing a placeholder for a third of a critical linkage field and pressing on treats a structural data gap as a cosmetic one — a fabricated placeholder for that much missing linkage data could quietly corrupt the scheduling logic Meridian depends on for FAA-compliant crew and gate assignments. Proceeding into Model Development on only the two-thirds of complete records, without reassessing sufficiency, risks training a model on a biased subset (records with connecting flights may differ systematically from those without) and skips the deliberate reassessment CPMAI calls for when a data assumption breaks down. Canceling outright overreacts — CPMAI's iterative loop exists precisely so a gap like this triggers a phase revisit and a revised plan, not an automatic project death sentence.