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?
Select an answer to reveal the explanation.
Short Explanation
Ground truth is only as good as the humans who made it. If the fraud labels are one analyst's inconsistent gut calls, the model will faithfully learn to reproduce that inconsistency — validate the labeling process, not just the file.
Full Explanation
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. Checking file-schema compliance is a technical/pipeline concern, not a ground-truth quality concern; a perfectly formatted file of bad labels is still bad ground truth. Verifying an equal split of fraudulent versus 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. The distractor about consistency alone is close but incomplete on its own without naming why it matters (the labels are the standard being reproduced) — the fully correct option ties consistency and sound reasoning to that reproduction risk explicitly. 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.