Data Readiness Decisions and Documentation

Overview
In the PMI Certified Professional in Managing AI (PMI-CPMAI) framework, Data Readiness Decisions and Documentation sits where data preparation ends and model development and evaluation begin. It is the formal checkpoint where the project team, data owners and stakeholders decide whether the prepared data is fit for purpose, meaning good enough in quality, quantity, relevance, compliance and representativeness to train and evaluate an AI model. The reasoning behind that decision is recorded in an auditable, traceable way.

The CPMAI methodology is iterative and data-centric, following phases similar to CRISP-DM:
1. Business Understanding
2. Data Understanding
3. Data Preparation
4. Model Development
5. Model Evaluation
6. Model Operationalization

Data readiness is the go/no-go gate between Data Preparation and Model Development. It is also revisited whenever evaluation shows data-related problems.

Why It Is Important
1. Most AI projects fail because of data, not algorithms. PMI and CPMAI stress that poor data quality, insufficient quantity, or data that does not represent the real problem are leading causes of failure. A formal readiness decision prevents teams from spending time and money training models on data that cannot support the business objective.
2. Garbage in, garbage out. Model performance is capped by data quality. Even a well-designed model trained on biased, incomplete or mislabeled data gives unreliable results.
3. Risk and compliance. Privacy laws (GDPR, HIPAA, CCPA), consent, licensing, intellectual property and data sovereignty must be confirmed before use. Documentation is evidence of due diligence.
4. Trustworthy and responsible AI. Documenting data sources, lineage, known biases and limitations supports transparency, explainability, fairness and accountability, which are core pillars of responsible AI.
5. Reproducibility and auditability. When a model is questioned, retrained or audited, the team must show exactly which data was used, how it was transformed and why it was judged acceptable.
6. Stakeholder alignment. A documented decision ensures sponsors, data stewards, domain experts and the technical team agree on the data's fitness and accept any residual risks.
7. Cost and schedule control. Finding data issues early is much cheaper than finding them after deployment.

What It Is
Data readiness has two connected parts:

1. The Data Readiness Decision
This is an evidence-based judgment, usually a go, no-go, or conditional go, about whether the data can move forward into model development. It is assessed against criteria such as:
- Quality: accuracy, completeness, consistency, validity, timeliness, uniqueness (no duplicates)
- Quantity: enough volume and enough examples per class, including minority or edge cases
- Relevance: the data actually relates to the business problem and the target variable
- Representativeness: the data reflects the real-world population and conditions the model will face in production
- Labeling: for supervised learning, labels are accurate and consistent, with acceptable inter-annotator agreement
- Bias and fairness: protected groups are assessed and skews are identified and mitigated
- Accessibility and availability: data can be obtained reliably now and in production, including for retraining
- Legal, ethical and compliance status: consent, privacy, licensing and security classification
- Data splits: training, validation and test sets are properly separated with no leakage

2. Data Readiness Documentation
These are the artifacts that record the data, its preparation and the decision. Common examples:
- Data inventory / data catalog entry: sources, owners, formats, volumes
- Data lineage and provenance records: where the data came from and how it was transformed
- Data quality assessment report: metrics, issues found, remediation applied
- Datasheets for Datasets / data cards: motivation, composition, collection process, preprocessing, intended uses, limitations
- Data dictionary: field definitions, types, allowed values
- Labeling guidelines and quality records
- Bias and representativeness analysis
- Privacy and compliance assessments: DPIA, consent verification, anonymization or pseudonymization methods
- Data versioning records: the dataset version tied to each model version
- Assumptions, constraints and risk log entries related to data
- Decision log / gate approval record: who decided, when, on what evidence, with what conditions

How It Works (Typical Process)
Step 1: Revisit business and AI objectives. Confirm what the model must achieve, the success criteria, and which data the AI pattern needs (for example classification, prediction, recognition, or conversational).
Step 2: Define readiness criteria up front. Set measurable thresholds with stakeholders. Examples: completeness of at least 95% for key fields, at least N labeled examples per class, label agreement of at least 0.8, and no unconsented PII.
Step 3: Assess the prepared data. Run profiling, quality checks, exploratory analysis, bias analysis and compliance reviews. Involve domain experts and data stewards.
Step 4: Compare results against the criteria. Identify gaps such as missing values, class imbalance, outdated records, unrepresentative samples or legal blockers.
Step 5: Decide. There are three possible outcomes:
- Go: the criteria are met, so proceed to model development.
- Conditional go: proceed with documented limitations, mitigations and monitoring, with risks formally accepted by the appropriate authority.
- No-go: iterate back to data understanding or preparation, acquire or augment data, relabel, rescope the problem, or even stop the project if the data cannot support it.
Step 6: Document everything. Record the evidence, the decision, decision-makers, assumptions, residual risks and the dataset version. Update the risk register and the project artifacts.
Step 7: Communicate. Share the outcome and implications with stakeholders. Make sure the sponsor understands the trade-offs.
Step 8: Revisit iteratively. If model evaluation shows underperformance caused by data, such as poor results for a subgroup, the team returns to the readiness assessment. In production, data drift monitoring triggers a reassessment.

Key Roles
- Project manager / AI project lead: facilitates the gate, makes sure criteria and documentation exist, and escalates risks
- Data owners and data stewards: confirm access, quality and appropriate use
- Data scientists and data engineers: perform assessments and preparation
- Domain / subject-matter experts: validate relevance and labels
- Legal, privacy and compliance officers: confirm lawful and ethical use
- Sponsor / governance board: approves the decision and accepts residual risk

Common Pitfalls
- Proceeding to modeling because of schedule pressure despite known data gaps
- Treating readiness as a one-time event instead of an iterative check
- Assuming that a large volume of data means quality data
- Ignoring representativeness, so the model works in testing but fails in production
- Data leakage between training and test sets, which inflates evaluation results
- Undocumented transformations, which make the work impossible to reproduce
- Missing the compliance check on consent or licensing
- Letting the data science team decide alone without business or governance input

Exam Tips: Answering Questions on Data Readiness Decisions and Documentation
1. Data first, model second. If a scenario shows data problems, the best answer almost always fixes, assesses or documents the data rather than tuning the algorithm, switching models or adding compute.
2. Do not skip the gate. Options that say "proceed with model development and fix data issues later" or "start training to save time" are usually wrong. CPMAI favors evidence-based go/no-go decisions.
3. Iteration is normal. Going back to Data Understanding or Data Preparation is a correct and expected CPMAI behavior, not a failure. Look for answers that return to an earlier phase when the evidence supports it.
4. Define criteria before assessing. The best answers set measurable readiness criteria aligned with the business objectives and agreed with stakeholders.
5. Documentation means traceability and accountability. Choose answers that record lineage, versions, assumptions, limitations and the decision rationale. Datasheets, data cards and decision logs are strong signals.
6. Watch for representativeness and bias. If the data does not reflect the production population, or a subgroup is underrepresented, the data is not ready, even if quality metrics look good.
7. Compliance is a hard blocker. Missing consent, unclear licensing or unprotected PII means no-go until it is resolved. Engage legal or privacy staff. Never "anonymize later" after training.
8. Conditional go requires formal risk acceptance. If proceeding with limitations, the right answer documents the limitations, adds mitigations or monitoring, and gets sign-off from the right authority, usually the sponsor or governance body.
9. Involve the right people. Prefer answers that include data stewards, domain experts and compliance, not just the data scientists.
10. Quantity is not quality. Distractors often imply that more data solves everything. Relevance, labeling accuracy and representativeness matter as much or more.
11. Spot data leakage. If evaluation results look suspiciously high, suspect leakage or improper splits and revisit data readiness.
12. Tie the answer back to business value. The readiness decision is ultimately about whether the data can support the business objective defined in Phase 1. Answers that connect data fitness to business success criteria are strong.
13. Pick the proactive, earliest-effective action. When several answers are plausible, choose the one that addresses the root cause earliest in the lifecycle and creates a documented record.
14. Keywords that signal correct answers: fit for purpose, evidence-based, traceable, versioned, documented assumptions, stakeholder sign-off, iterate, root cause, representative.
15. Keywords that signal distractors: skip, assume, later, ignore, the model will compensate, more compute, just collect more data (without analysis).

Sample Question Walkthrough
Scenario: A team has prepared customer data for a churn model. Profiling shows that 30% of records from a newly acquired region are missing key fields, and that region makes up 25% of future customers. The sponsor wants modeling to start next week. What should the project manager do?

Evaluate the options:
- Start modeling and handle the issue in evaluation: wrong, because it skips the gate.
- Drop the region's records: wrong, because it creates a representativeness and bias risk.
- Choose a more robust algorithm: wrong, because it is a model-first fix.
- Assess against readiness criteria, document the gap and its impact, present options to the sponsor and get a documented decision: correct.

The best answer is the last one. The options presented to the sponsor could include remediating or acquiring the data, a conditional go with a scoped limitation and monitoring, or adjusting the schedule. This answer is transparent, evidence-based, documented and aligned with stakeholders.

Summary
Data Readiness Decisions and Documentation make sure AI models are built only on data that is proven fit for purpose, and that the proof is recorded. For the exam, remember five things: define criteria, assess with evidence, decide go/no-go/conditional, document thoroughly, and iterate when needed. When in doubt, choose the answer that protects data integrity, compliance and traceability over speed.