Automatic Target Recognition — ATR — is a classification problem. The model takes an image, a radar return, or a multimodal input and assigns it to a class. The usefulness of the entire system depends on whether the classes are the right ones.

This is the part of ATR work that looks easy and isn't. The ontology — the taxonomy of classes the model will learn — is usually treated as a prerequisite to labeling. Someone writes down a list of classes, the labelers go to work, and the model is trained. When the model underperforms, the team reaches for more data, more architecture, more compute. The ontology is rarely questioned. It should be questioned first.

The Common Failure Modes

Too coarse. The classes lump together things the downstream user needs to distinguish. "Vehicle" is not useful when the operator needs to know "tracked combat vehicle" versus "wheeled utility vehicle." The model learns a distinction that is less informative than the raw imagery, which is worse than useless.

Too fine. The classes split at boundaries that are not reliably visible in the sensor data. If the difference between class A and class B is a feature that cannot be resolved at the typical collection range, the model will never learn the split and will produce confident errors.

Misaligned with user mental models. The ontology was written by an ML engineer in isolation. The operator who uses the output has a different taxonomy in their head. Every time the model outputs a class, the operator has to translate it mentally. The system gets used less, trusted less, and abandoned faster.

Inconsistent between labelers. The class definitions are underspecified. Two labelers looking at the same example assign different classes. The training set has noise baked in that no amount of data can average out.

Not versioned. The ontology evolves over the life of the program, but old labels don't get migrated, new labels don't get retrofitted, and the model ends up training on a Frankenstein taxonomy that nobody fully understands.

How To Actually Design An Ontology

The first rule is that the ontology is designed with the end user at the table. Not just reviewed — designed. The operator who will consume the model's output is the one who tells you what distinctions matter, at what granularity, and in what language. If you are designing an ATR ontology without an operator's voice in the room, you are designing the wrong ontology.

The second rule is that every class has an operational definition and a set of positive and negative exemplars. "Tracked combat vehicle" is not a class definition. A class definition is: here is the sensor modality, here are the collection ranges this applies to, here are the features that distinguish this class from adjacent classes, here are ten examples of the class under diverse conditions, and here are five examples that look like the class but are not.

The third rule is that the class hierarchy — not just the class list — is explicit. Models benefit from hierarchical structure. Operators benefit from the ability to query at different levels of granularity. The engineering team benefits from being able to evaluate performance at each level of the tree.

The fourth rule is that ambiguity classes exist. Not every example falls cleanly into a positive class. "Unknown," "obscured," "insufficient resolution" are first-class citizens in the ontology, not a junk drawer. The model that knows what it doesn't know is substantially more useful than the model that guesses confidently.

The Labeling Discipline That Enforces The Ontology

  • Every labeler goes through a calibration exercise before touching production data — a set of gold-standard examples with the expected labels
  • Inter-annotator agreement is measured, not assumed. Below a threshold, the class definition is wrong, not the labeler
  • Disagreements escalate to a named adjudicator with authority to update the class definition, and when the definition updates, prior labels are reviewed
  • The ontology version is stamped on every label. A label without an ontology version is garbage to future retraining
A model trained on a well-defined class with clean labels will outperform a model trained on ten times the data with a sloppy ontology. Every time.

Where The Ontology Work Lives In A Program

It is often an orphan activity. The ML team thinks it's the labelers' problem. The labelers think it's the program's problem. The program thinks it's the ML team's problem. Nobody owns it, which means nobody invests in it, which means it ends up as a five-line spreadsheet that gets treated as gospel for the next two years.

The fix is to name an ontology owner on the program, give them authority, and treat the ontology as a versioned deliverable alongside the model. The vendor that is doing the labeling should be pushing for this arrangement, because they bear the consequences of a bad ontology more than anyone else in the pipeline.

The Bottom Line

ATR models fail at class boundaries, and class boundaries are set by the ontology. Getting the ontology right is cheap compared to the cost of getting it wrong. It is also the part of the program that is most frequently skipped, most frequently under-resourced, and most frequently blamed on the model when it eventually breaks. Fix it first.