A team is preparing a time-ordered dataset of benefits applications to train a model that predicts approval outcomes. They split the data into training and test sets by randomly shuffling all records regardless of application date. What data-preparation problem does this random split risk introducing?

Mechanism: a random shuffle ignores the chronological order of applications, so records from later time periods, potentially reflecting policy changes, seasonal patterns, or shifts in applicant behavior that hadn't occurred yet, can end up in the training set alongside earlier test records, giving the model implicit access to future information it would never have at actual prediction time and producing an inflated, unrealistic sense of accuracy. Why the wrong options fail by concept: the split method doesn't change how many total records exist, it only changes how the same records are partitioned between training and test, so no new data is created. Splitting strategy has no bearing on the data types of the fields, those are determined by how the data was collected and processed, not by which rows land in which partition. The split method is unrelated to feature engineering, engineering features like encoding or scaling still needs to happen regardless of whether the split is random or time-based, dropping the shuffle doesn't eliminate that work. Scope caveat: a time-based split trades away some randomness benefits, like balanced representation of applicant types across the training and test sets, so the team should still check that the earlier training period reasonably represents the population the model will see going forward. Operational check: confirm every training record's application date precedes every test record's application date after implementing a time-based split.