Dataset quality guide
How to validate YOLO labels before training
Check YOLO labels, images, classes, and box geometry before starting a training run.
Start with the file contract
A YOLO detection row is class, center-x, center-y, width, and height. Before looking at a score, confirm that every label file has an image partner, class IDs map to the dataset YAML, and rows contain five finite values. A stray text file or a class index outside the configured range is a data-contract failure, not a model problem.
Check normalized coordinates
YOLO coordinates are normally normalized to the image dimensions. Centers should be inside the image and width and height must be positive. A row can look numerically plausible while its box extends beyond an edge. Review those findings against the image because clipping a legitimate object and accepting a malformed export are different decisions.
Compare class coverage by split
Count each class in train, validation, and test separately. A class that exists only in training cannot be evaluated honestly, and a class missing from training cannot be learned. Also inspect unusually small classes instead of relying only on the total annotation count.
Check image and label pairing
Nested folders, repeated basenames, and missing media can make a YOLO export look complete when it is not. Confirm that discovery preserves relative paths and that empty label files are interpreted deliberately rather than silently ignored. The Honest Numbers record includes a real failure where nested YOLO files could overwrite one another until path identity was preserved.
Review findings before a training run
Use the report as a repair queue. Prioritize invalid geometry, missing media, and class-map drift because they can stop or misdirect training. Keep the original export and the accepted corrections together so another reviewer can reproduce why a row changed.
Keep the check local and repeatable
Run the same check against the dataset revision that enters training. Labelyst processes the selected data on the device, then produces local findings and a report. For a repeated workflow, put the documented quality command and threshold beside the training configuration rather than relying on a one-time manual inspection.
Decide what blocks training
Set the decision rule before reading the report. Invalid annotations, missing media, split leakage, and incomplete coverage should block a training run until a reviewer resolves or deliberately accepts them. Less severe findings can still matter, but they need a documented disposition instead of being buried under a single aggregate score. The matching solution page explains which local checks apply to this dataset shape and why the result is limited when evidence is unavailable.
Keep evidence with the dataset revision
Save the local report, quality profile, and repair manifest beside the dataset version that entered training. That record lets a teammate reproduce the same finding, compare a later export, and distinguish a data change from a model change. A report is evidence from configured checks at a point in time. It is not a guarantee of model performance or an independent certification.
Repeat the check after every material change
Run the same local check again after relabeling, changing class mappings, moving images between splits, or accepting a vendor correction. Rechecking is more useful than carrying a historical score forward because the score only describes the records and coverage that were examined. For scripted review, keep the quality command and threshold in the training repository so a new dataset revision receives the same gate.
Check your dataset locally
Use the matching local check before starting a training run.