Start With the Business Objective

The one-page objective#

Five rows answer the questions every later step depends on. The defining project goals guide covers the same ground in more depth. Here is a filled-in warehouse example, which this course builds on:

Pin the page where the whole team can see it. If a stakeholder disputes a row later, change the page first and the dataset second.

Pick the simplest task that answers the question#

The task decides what annotators draw, and that decides most of the labeling budget. Work down this decision tree and stop at the first task that answers the business question:

Ultralytics YOLO supports seven tasks. For dataset planning, what matters is what each one costs to label; Computer Vision Foundations compares them in depth in its vision tasks lesson.

Read the banana panel as a price list: detection already answers presence, location, and count, and only the two segmentation panels add size and shape, at a much higher labeling cost. If the business only needs "how many bananas", detection is the answer, and polygons are wasted budget.

Write classes an annotator can apply#

A class is only useful if two annotators label the same object the same way. Write each one as a one-sentence definition that names a look-alike it excludes:

• forklift: a powered lift truck, including its forks and mast. Excludes hand pallet jacks.
• person: any human, including partly visible, seated, or inside a vehicle cab. Excludes reflections and posters.
• pallet: a wooden or plastic shipping pallet, loaded or empty. Excludes stacked crates without a pallet base.

Then choose the granularity deliberately. Coarse classes ("vehicle") are cheaper and converge faster; fine classes ("sedan", "pickup") are more useful downstream but harder to keep consistent. Start with what the business needs. Fine labels can be merged into coarse ones later with one line of code, but coarse labels can never be split without relabeling.

Turn the metric into an acceptance test you can run#

Pick the metric that matches the cost of a mistake:

• A miss is expensive (safety, defects): gate on recall for that class.
• A false alarm is expensive (auto-rejecting parts, alerting staff): gate on precision.
• Every class matters equally (counting, inventory): gate on per-class AP, so no class hides behind the average.

The YOLO performance metrics guide explains each one. Then write the test as code, so "is it good enough?" stops being a debate. This script runs today with a pretrained model on the COCO8 demo set, and later with your own checkpoint and holdout:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")  # later: your fine-tuned runs/detect/train/weights/best.pt
metrics = model.val(data="coco8.yaml", classes=[0], verbose=False)  # 0 = person; later: your holdout YAML

precision, recall = metrics.box.mp, metrics.box.mr
print(f"person: precision={precision:.2f} recall={recall:.2f}")
print("PASS" if recall >= 0.95 and precision >= 0.85 else "FAIL: below the acceptance test")

                   all          4         10      0.939        0.8      0.848      0.387
person: precision=0.94 recall=0.80
FAIL: below the acceptance test

What each line tells you:

• classes=[0] scores only person, so other classes cannot pad the result. Use your own safety class ID.
• The validator row shows 4 images with 10 labeled people. mp and mr are precision and recall at the confidence threshold that balances them best (maximum F1).
• A pretrained COCO model finds 8 of the 10 people, so recall is 0.80: precise, but not safe enough. That FAIL is the test doing its job. In this course, a FAIL leads back to the data, not to hyperparameters.

Write down what v1 won't do#

No model is perfect, so name the acceptable misses up front: conditions you won't promise (heavy fog, total darkness), look-alikes you'll tolerate confusing, and long-tail classes deferred to v2. This row keeps a model that meets its target from being judged against an unwritten 100% bar, and it tells the collection team where not to spend effort yet.