Meridian's loyalty-program fraud team has a labeled dataset of past mileage-redemption cases marked "fraudulent" or "legitimate" by fraud analysts. Before the model can be trusted, the project manager wants to validate this "ground truth." Which activity most directly validates ground-truth quality for this dataset?

Ground truth is the label set the model is trained to reproduce, so validating it means checking that the labeling process itself was consistent and well-reasoned — inter-analyst agreement, documented criteria, and a review or audit step — not just checking the data's technical packaging. The correct activity is checking that multiple analysts or a documented review process labeled cases consistently and with sound reasoning, because the labels themselves are the standard the model will be trained to reproduce. Checking that the file format matches the schema expected by the model-training pipeline is a technical/pipeline concern, not a ground-truth quality concern; a perfectly formatted file of bad labels is still bad ground truth. Checking that the labels match the model's predictions, since a high agreement score confirms the labels are accurate, is circular: the model's predictions are not the authority on label correctness, and agreement can simply mean the model has learned the same errors or biases present in the labels. Verifying that the dataset contains an equal number of fraudulent and legitimate cases addresses class balance, a data-preparation and bias concern, not label correctness — a balanced dataset can still be wrong if the labels are inconsistent, and fraud is naturally imbalanced (mostly legitimate cases), so forcing an artificial 50/50 split isn't even appropriate here. If Meridian's fraud labels reflect one analyst's inconsistent or biased judgment, the trained model won't just underperform, it will systematically learn and scale that analyst's blind spots across every future redemption the system screens.