Start with the decision, not the available dataset
A dataset can be clean and still be unsuitable for a use case. Readiness depends on what the model will influence, who is affected, what error means, how quickly conditions change and what a human can do when confidence is low. These questions establish which facts are material and how much evidence is needed.
Define the intended recommendation or action in plain operational terms. Identify the owner, user, subject, decision timing, alternatives and consequences. Then trace the data needed to support it. This prevents an attractive dataset from creating a use case that the organisation cannot responsibly operate.
Shared meaning is a production dependency
Training and operational systems may use the same label for different concepts. A customer can mean an account, legal person, household or active contract. A closed case can mean resolved, administratively ended or abandoned. If the meaning differs by period, source or team, model behaviour can change for reasons the evaluation never tested.
Critical features and outcomes need business definitions, inclusion and exclusion rules, time context and accountable owners. Historical changes should be visible. The objective is not to document every field but to make the meanings that materially affect the decision stable enough to challenge and monitor.
Provenance must reach the operational decision
Lineage is useful when it explains where a value came from, which transformations changed it and under which rule or version it entered training, evaluation and production. A technical pipeline graph may show movement while omitting the business selection and correction decisions that shaped the data.
Record provenance at a level proportionate to risk. The team should be able to investigate an outcome, assess the impact of a source change and reproduce the relevant evaluation. If data is enriched or labelled by people or suppliers, that context and its quality controls belong in the lineage view.
Connect quality controls to consequence
Global completeness and accuracy scores are weak readiness tests. A rare missing value can be material if it removes a safety or eligibility condition, while a frequent defect may be irrelevant to the intended decision. Define quality against use: valid ranges, timeliness, representativeness, consistency, duplication and label reliability where they affect the outcome.
For each critical defect, decide whether to prevent, detect, correct, reject, escalate or expose uncertainty to a human. Assign an owner and threshold for action. These controls should operate after deployment as well as during preparation, because production sources and behaviour will change.
Evaluation data must represent operating conditions
An evaluation set should reflect the cases, time periods, exceptions and populations the capability will encounter, including conditions in which the model should defer. Separation from training matters, but so do leakage through related entities, post-outcome information and manual corrections that will not exist at decision time.
Define acceptance around the business action, not one aggregate model score. Include important error classes, human review capacity, latency, failure behaviour and the cost of abstention. Record the dataset and rule versions so a later change can be compared meaningfully.
Production needs a feedback and change system
Data readiness is not completed at launch. Source systems change, definitions move, operational behaviour adapts and the population may shift. Monitoring should cover input conditions, data controls, model behaviour, human overrides, outcome evidence and unresolved exceptions at a cadence the decision risk justifies.
The organisation also needs authority to respond: who investigates, who can suspend automation, how fallback works, when retraining or redesign is considered and what evidence permits a return to service. Without this operating model, a model can remain technically available while its decision context has already changed.