cross-validation.

Where cross-validation fits on a long engagement.

The standard errors are about splitting, not about the method. Random splits on grouped data — multiple rows per customer — put the same entity in training and validation, which inflates the score because the model has effectively seen the answer. Grouped splitting is required whenever rows are not independent.

Preprocessing inside the validation loop is the other common leak. Scaling or imputing using statistics computed over the whole dataset leaks validation information into training, and the resulting estimate is optimistic in a way that only becomes visible in production.

What an assigned team does with cross-validation.

An optimistic validation estimate is worse than no estimate, because decisions get made on it. A model deployed on the strength of an inflated score consumes the credibility of the next project as well as its own.

Rigour here is a professional standard rather than a preference, and it is what the assigned specialists are held to under managed ai services.

What we use cross-validation for.

• Grouped splits where rows are related Entities kept whole across folds, so the score is not inflated.
• Preprocessing fitted inside the fold Statistics computed on training data only, preventing a subtle leak.
• Time order respected Forward-chaining validation on temporal data rather than random shuffling.

How cross-validation capacity is assigned.

Model evaluation is assigned inside AI capacity, with validation methodology treated as part of the deliverable rather than an implementation detail.