> For the complete documentation index, see [llms.txt](https://docs.unitlab.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unitlab.ai/documentation/auto-labeling/batch-classification.md).

# Batch Classification

Classify project cohorts operationally by applying governed tags to selected items without confusing metadata with ontology labels.

Batch Classification applies one project tag to many selected items from the project data view. It is a fast way to create operational cohorts such as **needs-review**, **night**, **domain-a**, **priority-source**, or **holdout**.

![Project data view where operators select the items to classify with tags](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2FIvRvqpp8ADPDmutKSJ1M%2Fproject-data-clean.png?alt=media\&token=22df8e5b-6943-4e6a-a2e9-c69a47818c0c)

*Open a project’s data view, select items, then use the selection action bar.*

{% hint style="info" %}
Project tags are metadata for filtering and operations. They are not ontology classifications. Use an **Item Property** when the value must be part of the annotation schema, versioned ground truth, or export.
{% endhint %}

### Choose tags or Item Properties

| Need                                                 | Use                    |
| ---------------------------------------------------- | ---------------------- |
| Build a temporary operational cohort                 | Project tag            |
| Filter and assign a batch                            | Project tag            |
| Mark source, campaign, or intake state               | Project tag            |
| Train a model on an image-level class                | Ontology Item Property |
| Require a reviewer to validate the value             | Ontology Item Property |
| Export the value as governed annotation ground truth | Ontology Item Property |

### Apply a tag to selected items

{% stepper %}
{% step %}

#### Open the project

Open **Projects**, choose the project, then open its **Data / Datasets** view.
{% endstep %}

{% step %}

#### Narrow the population

Use status, assignee, class, source, file, tag, or advanced filters so the visible set represents the intended cohort.
{% endstep %}

{% step %}

#### Select items

Select individual rows or cards. Use **Select all** only after confirming whether it targets the current page or the complete filtered result set.
{% endstep %}

{% step %}

#### Open Tags

The bulk action bar appears after selection. Choose **Tags**.
{% endstep %}

{% step %}

#### Choose or create a tag

Select an existing project tag or create a new name. Tag names are limited to 50 characters in the current UI.
{% endstep %}

{% step %}

#### Apply and verify

Unitlab adds the tag to the selected items. Filter by the new tag and confirm the count and sample before using the cohort in assignment, review, or release decisions.
{% endstep %}
{% endstepper %}

### Naming conventions

Prefer stable, machine-readable names:

| Pattern           | Example                    |
| ----------------- | -------------------------- |
| Domain            | **domain-construction**    |
| Capture condition | **condition-night**        |
| QA state          | **qa-needs-expert-review** |
| Source            | **source-partner-a**       |
| Experiment        | **exp-vehicle-v3-holdout** |

Avoid tags such as **good**, **final**, or **test** without a documented owner and meaning. They become ambiguous across teams and time.

### Bulk-action safeguards

Before applying a tag to a large population:

* clear unrelated selections left from another view;
* inspect active filters and the selected count;
* confirm archived items are excluded unless intentionally targeted;
* use a small sample when introducing a new naming convention;
* avoid encoding sensitive information in a tag name;
* record the cohort definition when it affects training or evaluation.

### Verify the cohort

1. Filter the project by the tag.
2. Compare the result count with the selection count.
3. Open representative items from different sources and statuses.
4. Confirm no unintended archived or failed items are included.
5. If the cohort feeds a dataset or release, record the filter and tag definition.

### Common mistakes

| Mistake                                          | Consequence                                       | Correction                                                     |
| ------------------------------------------------ | ------------------------------------------------- | -------------------------------------------------------------- |
| Using a tag as ground truth                      | Value may not follow ontology/review/export rules | Create an Item Property and route through review               |
| Applying to all filtered results unintentionally | Cohort becomes too broad                          | Inspect selection scope and undo/correct before downstream use |
| Reusing an ambiguous tag                         | Different teams interpret it differently          | Rename by convention and document the definition               |
| Encoding PHI or secrets in tags                  | Sensitive data leaks into operational metadata    | Use approved identifiers and governance controls               |

### Related guides

* [Project data](/documentation/projects/project-data.md)
* [Data curation](/documentation/data/data-curation.md)
* [Properties, relations, and Item Properties](/documentation/ontologies/properties-relations-and-item-properties.md)
* [Attach datasets to projects](/documentation/datasets/attach-datasets-to-projects.md)