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

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

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.

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

1

Open the project

Open Projects, choose the project, then open its Data / Datasets view.

2

Narrow the population

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

3

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.

4

Open Tags

The bulk action bar appears after selection. Choose Tags.

5

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.

6

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.

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

• Data curation

• Properties, relations, and Item Properties

• Attach datasets to projects