Machine Learning Data Readiness: A Source-Contract Checklist

Is your data ready for a machine learning project?

Data readiness is not a single cleanliness score. A useful assessment asks whether the information available at prediction time can support a defined decision, whether the target outcome is measurable, and whether the same preparation can run reliably after deployment. More rows will not repair an ambiguous label or an unstable business definition.

Start with one decision: which orders need attention, which customers may leave, or how much stock should be available. Specify who receives the prediction and what action follows. Then examine the source contracts behind the proposed model. This article focuses on those contracts rather than selecting a modeling algorithm.

Define the prediction time and label

Document the exact moment at which a prediction would be made. Features must come from information legitimately available at that moment. A field populated after the outcome, such as a final resolution code, can make an offline model look convincing while being unavailable in production. That is a form of leakage.

Write the outcome definition in ordinary language before translating it into a query. For an illustrative churn project, distinguish inactivity, voluntary cancellation and payment failure rather than treating them as interchangeable. This is a hypothetical design example, not an Izan customer result.

Ask how long it takes for labels to become trustworthy. If an outcome can change after initial recording, define a settlement period and label revision policy. Otherwise yesterday's training set may have different answers when rebuilt next month.

Create a source-contract worksheet

Record each dataset's business key, row grain, timestamp meaning, source owner and permitted use. Include a field-level mapping with units, null rules and timezone conventions. Numeric identifiers should not automatically become numeric predictors, and a date-looking string should not be converted without agreeing its format.

Useful readiness checks include:

1. Identity: can records be matched across sources without unintentionally merging distinct people or orders?
2. Availability: does each candidate feature exist when the prediction is needed?
3. Coverage: which groups or time periods are missing, and could that alter the model's usefulness?
4. Stability: did the source definition change during the historical period?
5. Repeatability: can the same transformations be run on a future batch?
6. Permission: is the proposed use consistent with the data owner's access and retention rules?

For each issue, record impact, a proposed remedy and an accountable owner. A readiness assessment is more useful when it produces decisions than when it produces an undifferentiated list of defects.

Separate exploration from production evidence

Exploratory joins and charts help expose duplicates, unusual distributions and missing values. They do not establish predictive performance. Evaluate a model on data excluded from training, and choose a split that reflects the intended deployment. Time-dependent forecasts need careful attention to chronology; random splitting can hide a mismatch between historical evaluation and future use.

Compare the proposed model against a simple baseline and assess the cost of false positives and false negatives. A technically better score may still be operationally unsuitable if staff cannot act on its output. Decide how predictions will be monitored and how changes to source data will be detected.

Microsoft's ETL documentation explains data shaping, cleaning and pipeline coordination. Its data integration pattern guidance considers use case and data characteristics. Those are foundations for consistent inputs, not guarantees of model accuracy.

What to bring to a consultation

Bring a description of the decision, a sample field dictionary, the available historical period, known quality problems and the person who owns the outcome definition. Avoid sharing personal or confidential records until access and handling have been agreed.

You'll Love Our Smart AI Data Studio (Demo), Try It to explore file preparation, field mapping, joins, SQL and dashboards. Personal-demo ML Insights and Graphs & Trees are locked; the preparation workflow remains available. Files are limited to 100MB each in the demo, while a deployed solution can support 5GB uploads. Authorized live integrations require their own setup.

Izan Technologies builds custom AI, ML and data engineering solutions, and customers own all IP in everything we build, provide or deliver. Talk to an expert about a scoped readiness assessment and see our services.