Exploratory work shows that duplicate and missing source records explain most of an apparent performance spike, yet modelers want to proceed with a complex predictive model anyway. What sequencing decision is correct?
Select an answer to reveal the explanation.
Short Explanation
If dirty data is doing most of the talking, building a fancy model is like polishing a cracked windshield and then racing. Fix the duplicates and missingness at the source, then model what's left. Otherwise you're predicting the defects, not the service.
Full Explanation
When exploratory work shows duplicate and missing source records explain most of an apparent performance spike, the correct sequencing is to pause elaborate predictive modeling and remediate dominant data quality defects at the sources first. Models trained on broken identity and completeness learn artifacts and can automate false operational confidence. Tuning hyperparameters until the spike looks like a genuine signal papers over upstream defects. Averaging duplicates into the feature set so the model “absorbs” defects encodes the error rather than fixing it. Publishing the model and filing a DQ ticket afterward if anyone complains reverses priorities and can harm residents subject to model-driven actions. Exam caveat: not every minor DQ issue blocks all modeling, but when DQ explains most of the signal under study, remediation comes first. Operational check: quantify how much of the spike is removed after deduplication and completeness fixes, assign source owners to defects, re-measure, and only then reconsider whether predictive work is still warranted. In municipal information-management practice, record the rationale so future staff know which failure modes the rejected options would create for city services, and re-validate after the next cycle that the same control still holds.