Manage Data Transformation and Data Preparation

Phase 3 Is Where the Project Actually Spends Its Time

CPMAI Phase 3, Data Preparation, converts the raw data you accepted at the Domain III data-sufficiency gate into a dataset a model can actually be trained on. It is routinely the largest single block of effort on an artificial intelligence (AI) project, and it is the phase most consistently under-estimated when the schedule is drawn up. PMI publishes no figure for how much of a project it should consume, and the widely quoted percentages come from surveys of how data scientists spend their week rather than from project accounting, so plan it from your own phase estimates and record the actual against them at closeout. Schedules that budget Phase 3 as a short technical step are the ones that slip.

ECO Domain IV, Task 4 does not ask you to write the transformations. It asks you to manage them: to ensure the decisions buried inside them are made by the right people, recorded, and reproducible. Nearly every trap in this task is a technically competent transformation applied by the wrong authority or left undocumented.

Cleaning and Preprocessing: Business Decisions in Disguise

A data engineer cleaning a claims table makes rulings that look technical and are not.

• Missing values. A blank field can mean "not applicable", "not captured by this channel", or a genuine zero. Each meaning implies a different treatment — drop the row, impute a value, or add an explicit "unknown" indicator. Only a subject-matter expert (SME) knows which applies, and the wrong choice quietly teaches the model something false.
• Outliers. Removing extreme values steadies some model families. But in fraud detection, anomaly monitoring, or equipment-failure prediction, the outliers are the target class. "Remove or keep" is a business ruling about what the model exists to find.
• Duplicates and entity resolution. When two customer records match imperfectly, someone must decide which is the system of record and how conflicting fields are merged. That is a data-governance decision, not a scripting preference.

Your job is to force each ruling to be explicit rather than defaulted by whoever happened to open the notebook. Every ruling gets a named decider and a written entry in the data preparation log — the document that answers the auditor or the puzzled business owner two years later.

Feature Engineering: Where Domain Knowledge Enters the Model

Feature engineering turns raw fields into the signals a model learns from: transactions in the last 24 hours, days since last service, the ratio of claim amount to policy limit, whether a shipment crossed a weekend. This is the single point in the lifecycle where human expertise is deliberately injected, so convene the SME sessions yourself and insist features are defined in business language before they are coded.

Ask one question of every proposed feature: will this value be available, with the same meaning, at the moment of prediction? A field that is only populated after the outcome is known produces a spectacular model and a worthless one. (The formal check for that belongs to the readiness gate in the next section.)

Feature selection is a management trade-off, not a purity exercise. Each retained feature buys marginal signal and creates a permanent liability: an upstream source to monitor, a data contract with another team, another way the pipeline breaks at 3 a.m. Ask what a feature costs to maintain for three years, not just what it adds to a validation score.

Normalization, Standardization, and the Production Rule

Some model families compute distances or gradients across features, so a field measured in millions swamps one measured in single digits unless the values are rescaled. Normalization (compressing to a fixed range) and standardization (recentring around a common mean and spread) remove that artifact. Tree-based models are largely indifferent; distance-based and neural models are not. That is the whole depth a manager needs: the model family determines whether scaling is required.

The operational rule matters far more than the mathematics. The exact same transformations must run in production as in training. Scaling constants, imputation defaults, and the vocabulary of known categories are learned artifacts: fitted on training data, then versioned and shipped alongside the model rather than recomputed from whatever arrives at serving time. When production recomputes them, identical inputs are transformed differently than in training, scores drift for no visible reason, and the team chases a phantom modeling problem. This mismatch — train/serve skew — is a leading cause of AI systems that evaluate beautifully and underperform on day one.

Augmentation and Synthetic Data: Use and Limits

Data augmentation creates additional training examples from existing ones; synthetic data generation creates artificial records that imitate the statistical structure of real ones. Both have legitimate uses:

• Rare-class balancing — a fraud rate of 0.3 percent gives an algorithm almost nothing to learn from, so the minority class is amplified in training.
• Privacy-preserving development data — engineers build and test against synthetic records rather than real patient or customer data.
• Rarely observed conditions — augmented images of a defect type that appears twice a year.

The limits are absolute and the exam tests them. Synthetic data cannot create information that was never observed. A generator trained on a population that barely contains self-employed applicants cannot invent what they really look like; it reproduces and amplifies whatever bias the seed data carried, and can collapse onto a narrow band of repeated patterns. Two rules follow. Augmentation and balancing apply to the training split only, never to validation or test. And a model validated only on synthetic data is not validated — final evaluation runs on real, observed records at the real event rate. Synthetic data also inherits the privacy classification of its seed.

Reproducibility and Documentation

Transformations live in versioned pipeline code, not in an analyst's notebook or a spreadsheet. The test is blunt: given the same raw extract, can the pipeline be re-run today and produce the same prepared dataset? If not, you cannot investigate a production incident, retrain on a comparable basis, or answer an auditor. Pin a dataset version identifier to every model version, keep the decision log of SME rulings with it, and require that any correction — however small — be implemented in the pipeline rather than applied by hand.

Regenerability, Not Performance, Is the Acceptance Test

A transformation applied by hand and undocumented is a defect, even when the model performs well. Performance is not the acceptance criterion for Phase 3 work; regenerability is. When a scenario tells you an analyst corrected records in a spreadsheet, fixed a join manually, or tuned a threshold "just for this run", the correct managerial response is to have the change reimplemented in the versioned pipeline and the dataset regenerated — not to log a risk and move on.