Define the Required Data

Start at the Decision, Not the Warehouse

Domain III of the Exam Content Outline is Identify Data Needs, worth 26% — tied for the largest domain on the exam — and it maps to CPMAI Phase 2, Data Understanding. Its first task, define required data, is your last cheap opportunity to change the shape of the project. The discipline is to work backwards from the decision: name what the business will do differently, name the target variable the model must predict, then derive what has to be labeled, at what grain, over how much history, and at what quality.

Mapping data requirements to business objectives means every requirement traces to a line in the scope statement or the success criteria agreed in Domain II. A demand-forecasting project whose KPI is cutting stockouts at store-SKU level is not served by regional weekly sales — the requirement is store-SKU-day. When a data owner later asks why you need a field, the answer should be one sentence, not a meeting.

Specify Data Types and Formats — and Price Them

Data type drives effort far more than raw volume does.

• Structured tabular — transactions, accounts, claim lines. Cheapest to profile; the work is in joins, keys and reconciling definitions across systems.
• Free text — case notes, tickets, claim narratives. Needs labeling or extraction, and hides the most unmanaged personal data in the organization.
• Images and video — inspection photos, scans, shelf cameras. Annotation dominates the budget and the calendar.
• Audio — call recordings. Adds transcription cost plus consent and recording-law constraints.
• Time series — meter, sensor and telemetry readings at fixed intervals, where gaps are themselves information.
• Event streams — clickstream and application logs. Enormous volume, and meaningless until sessionized.

Format means more than a file extension. Record the schema and units, the code lists and what each code means, the join keys, how missing values are represented, and how the data will be delivered — one-off extract, scheduled file, API or stream. Two systems that both call a field 'status' are not interchangeable.

Determine Volume and Sampling Strategy

'How much data do we need?' has no universal answer, and any exam option that supplies a single magic number is wrong. Volume requirements are driven by four things:

1. Number of features — more columns need more rows before a pattern is trustworthy.
2. Class balance — for rare events, what matters is the absolute count of the minority class. A fraud bank with 0.3% positives needs enough frauds, not enough transactions.
3. Signal strength — a weak relationship needs far more evidence than an obvious one.
4. Model complexity — a complex model demands more data than a simple, interpretable one, which is one reason CPMAI favors the simplest model that meets the agreed success criteria.

Sampling strategies follow from this. Random samples are fine for profiling. Stratified sampling — sampling within defined strata so rare classes and small segments stay proportionally represented — is the standard answer for imbalanced problems such as fraud, equipment failure or serious adverse events. Time-ordered splits are required for anything with a time dimension. Whatever you choose, the sample must represent the population the model will actually serve in production, and the choice must be documented.

Temporal Requirements and Point-in-Time Correctness

Three separate questions hide inside 'we need historical data':

• History depth — enough to cover complete seasonal cycles and any regime change the model must survive: a pricing change, a policy switch, a disrupted year. Two years of retail history containing one anomalous year is not two usable years.
• Refresh frequency and latency — how fresh a value must be when the model scores. If a feature refreshes nightly but the decision is real time, that feature is unusable as specified.
• Point-in-time correctness — never train on information that would not have existed at the moment of prediction. This is leakage, and it is the single most common reason a model that validated brilliantly collapses in production. A cancellation-reason field written after the customer churned predicts churn perfectly and is worthless. For every field ask: when was this value written, and would we have had it at decision time?

Granularity Must Match the Decision

Granularity is what one row represents: per transaction, per customer-month, per store-day, per sensor-minute. Set it from the decision. If the business decides which customers to contact each week, the grain is customer-week, and the label must sit at the same grain as the features. Aggregating up is irreversible — you cannot recover transaction detail from monthly totals — while going finer than the decision needs inflates cost for no benefit.

Write Quality Standards as Acceptance Criteria

Data quality standards belong in numbers, with a measurement method and an owner, exactly like any other acceptance criterion:

• Completeness — at least 98% of active contracts carry a non-null start date.
• Accuracy — 200 sampled records checked against source documents, at least 95% matching.
• Timeliness — transaction records land within 24 hours of the event.
• Consistency — customer identifiers reconcile between billing and CRM for at least 99% of accounts.
• Validity — every state code appears in the reference list; no negative tenure values.
• Uniqueness — duplicate customer records below 0.5%.

These thresholds become the measuring stick for the data-quality go/no-go later in the project. Agree them now, while nobody is emotionally invested in the result.

Requirement Dimensions at a Glance

The Trap the Exam Sets

The wrong instinct — and the most common real-world failure — is defining data requirements from what is conveniently available. If your requirements list is exactly the columns in an existing warehouse extract, you have described the extract, not the problem. The correct sequence is: define what is needed, inventory what exists, compare, and record every gap as a documented risk, a data-acquisition work package, or a scope change the sponsor decides on. Data Understanding is allowed to send you back to Business Understanding; that iteration is CPMAI working as designed, not the project failing.