5.4 Data Preparation Activities

Data preparation is where many ML failures start

Learning objective AI-3.2.1 (K2) asks you to explain the activities related to data preparation. Treat this as a core testing topic, not as janitorial work that happens before the interesting modeling begins. Data preparation is one of the most crucial and resource-intensive activities in the ML workflow. It typically consumes a significantly larger proportion of overall effort than stages such as model selection and building. It is also tightly linked to the data pipeline that turns raw records into the form both training and live prediction expect.

The safety sentence is equally examinable: if operational data differs significantly from training data, ML functional performance and safety assumptions may no longer hold. A braking model trained on dry-track telemetry does not get to keep its safety case when the car is deployed on ice. A medical triage model trained on adult records does not get to keep its performance story on infants. Matching characteristics—distributions, feature ranges, modalities—is not a courtesy. It is a condition for the claims you accepted in the workflow’s first box.

Data acquisition: types, sources, and labels

Data acquisition starts by identifying relevant data types. CT-AI’s list is broad on purpose. Acquired data can be numerical, categorical, image, tabular, text, time series, sensor, geospatial, video, and audio. A single system may mix them: a predictive-maintenance project might join sensor time series, categorical fault codes, and free-text work orders. If you identify the wrong types, you will build the wrong pipeline and then wonder why the model is blind.

Acquisition continues by gathering data from diverse sources, such as databases, APIs, or real-time sensors. Each source has its own clock, its own missingness pattern, and its own access-control story. API extracts that silently drop night-shift records will bias any model of 24-hour operations. Sensor streams that pause during maintenance windows will look like miraculously stable machines.

For supervised tasks, acquisition includes labeling, with accuracy and consistency checked. Labeling is where supervised learning actually becomes supervised. Two annotators who disagree on whether an X-ray shows a finding are not a people problem off to the side of ML. They are injecting noise into the teacher column. Testers should ask who labeled, against which written definition, with what agreement checks, and how disagreements were resolved. A high label throughput with no consistency check is not speed. It is a defect generator.

Data preprocessing: make the table honest enough to learn from

Data preprocessing is the family of transforms that clean and reshape what was acquired.

Cleaning includes:

• Removing defects, duplicates, and outliers so accuracy and consistency of the records can be trusted. Duplicates can leak the same patient into training and holdout. Outliers may be sensor spikes that should be dropped, or rare safety events that must never be dropped. Blind outlier deletion is a safety risk of its own.
• Imputing missing values using techniques such as mean, median, or mode so the dataset stays complete enough to train. Mean and median apply to numerical fields (median is often sturdier when a few extreme values would drag a mean). Mode applies to categorical fields. Imputation is a design choice: filling missing blood pressure with a population mean can hide the very patients who skipped measurement because they were unstable.
• Anonymizing or removing personal information to protect privacy and meet regulations. If a name, national id, or exact address is not a legitimate feature, it should not sit in the training mart. Residual identifiers in free text are a common leak.

Preprocessing also transforms data formats and scales or normalizes values so features sit on comparable ranges. A salary in dollars and an age in years will otherwise let the larger-magnitude field dominate some algorithms for no semantic reason.

Augmentation increases sample size. CT-AI explicitly includes adversarial examples to strengthen robustness against adversarial attacks, and generating synthetic data. Augmentation is not an excuse to invent labels you could not justify on real records. Synthetic rows that copy majority-class stereotypes will bake those stereotypes in. Adversarial examples that only cover one attack family can create a false sense of hardness.

Sampling subsets reduces training time and computational cost. Sampling is a budget tool with a fairness and representativeness cost. If you undersample a rare failure mode to save GPU hours, you may train a model that never sees the failure it was supposed to catch.

Feature engineering: choose what the model is allowed to see

Feature engineering has two syllabus jobs:

• Selecting relevant features based on their contribution to ML model performance.
• Extracting a subset of informative and non-redundant features from existing features to reduce training times and computational costs.

Selection is about contribution: a column that does not help the task is noise, leakage, or expense. Extraction is about a smaller, informative, non-redundant subset—turning raw timestamps into hour-of-week, or collapsing collinear sensor channels, rather than feeding every raw column twice. Testers should watch for target leakage dressed up as a clever feature (the future repair-cost field used to predict whether a part will fail) and for redundant features that make explanations unstable.

Feature work is where domain testers often beat generic data cleanup. They know which code means cancelled, which geospatial field is the billing address rather than the incident location, and which audio channel is the radio chatter rather than the machine.

EDA runs in parallel, and the whole job is iterative

In parallel with acquisition, preprocessing, and feature engineering, teams typically perform exploratory data analysis (EDA) to understand the data. EDA includes:

• Discovering trends, patterns, and anomalies
• Visualizing data with plots and charts

EDA is how you notice that 80% of labels arrived on weekdays, that one sensor saturates at a rail, or that a class balance flipped after a policy change. It is not a slideshow for stakeholders. It is an investigation that should change preparation choices.

Preparing training data is typically iterative, often manual, and individual activities may be reordered or omitted based on project needs. There is no single legally required order such as always impute before you ever plot. Omitting a step is allowed when it does not apply (you cannot anonymize personal names that were never collected). Omitting a step that does apply is how you ship a model trained on duplicates and missing targets.

Production may change the steps, not the characteristics

Operational data should match the characteristics of the training data, for example distributions and feature ranges, so the model behaves as expected in production. The preparation steps themselves may be adjusted for production efficiency and scalability. That pairing is easy to misread. It does not mean production can silently drop a scaling transform the model was trained on. It means a production pipeline might use faster implementations, more automation, or different storage, provided the resulting data characteristics still match training.

If training normalized pixel intensities to a 0–1 range and production sends 0–255 bytes, characteristics do not match. If training included a rare weather bin and production sampling drops it to save bandwidth, characteristics do not match. Efficiency is allowed. Silent distribution shift is not.

A compact tester checklist for AI-3.2.1

When an exam story describes a data-preparation project, name the activity:

Data preparation is where testers with domain knowledge prevent the rest of the workflow from becoming an expensive demonstration that the team can train on the wrong world.