Project data QA

Inspect project work as a cohort with the project Embedding view, status filters, and Display View controls.

Project Data QA answers a different question from Data Space curation: is the exact population attached to this project ready to be annotated, reviewed, and released? Work from Project › Data so every filter, visual sample, and Workbench link refers to this project's Data Units and workflow state.

The project Embedding view is not the Data Space embedding explorer. It is scoped to the current project and combines visual neighborhoods with project statuses, assignment, classes, and direct Workbench entry.

Inspect the project population in Embedding view

Project Data Embedding view with project filters and Workbench cards

Project Embedding view clusters the current project's Data Units while retaining project status, assignment, class filters, and Workbench access.

Open the project, choose Data, then switch from Grid or List to Embedding view. Read the page in three layers:

1. The plot shows visual proximity between project items. A dense neighborhood may represent repeated acquisition conditions, similar content, or duplicated scenes; an isolated point may be a rare case, an error, or a valuable edge case.

2. The item cards identify the underlying Data Units. Open representative cards in Workbench before drawing a quality conclusion from the plot.

3. The project filters narrow the population by lifecycle state such as New, Processing, In annotation, In Review, Complete, Invalid, or Archived, and by assignment or class where available.

Embedding distance is an investigation signal, not a quality score. Confirm every suspected cluster, gap, or outlier against the source item, active Instructions, ontology, and workflow state.

Control how annotations render with Display View

Project Display View panel beside the Embedding view

Display View changes how project annotations appear in visual previews; it does not change the stored annotation, workflow state, or source media.

Choose the Display View control beside the Grid, List, and Embedding selectors. The panel provides a shared rendering policy for the current project view:

Control	What it changes	When to use it
Show object names	Adds class or object labels to rendered annotations.	Check class confusion, naming consistency, or crowded scenes.
Color by object ID	Colors instances by identity instead of only by class.	Inspect tracking identity, overlaps, or same-class instances.
Crop view	Crops previews around annotations.	Compare boundary quality or small objects without opening every item.
Additional zoom	Adds crop magnification after Crop view is enabled.	Review fine edges, small defects, or dense local regions.
Boundary thickness	Changes the rendered outline width.	Keep thin geometry visible without obscuring the source.
Border, vector, and mask opacity	Balances annotation visibility against source evidence.	Inspect occlusion, segmentation leakage, and overlapping geometry.
Classes	Shows or hides selected classes in previews.	Isolate one ontology concept or compare class-specific coverage.

When Properties or Attributes are available for the rendered classes, use their Display View controls to isolate the values relevant to the QA question. Display settings are presentation-only; use Workbench to correct labels and workflow actions to route work.

Run a cohort-level QA pass

1

1. Define the question

Name the failure mode before filtering—for example unreviewed edge cases, rejected work, invalid media, missing class coverage, identity drift, or a recently changed ontology branch.

2

2. Build the project cohort

Combine project status, assignment, class, source, and saved filters. Record the criteria when the cohort will be reviewed repeatedly.

3

3. Inspect the distribution

Use Embedding view to find neighborhoods and outliers; use Grid for visual comparison and List for exact operational fields.

4

4. Tune Display View

Show only the classes and rendering layers needed for the question. Use object-ID color, crop, zoom, thickness, and opacity deliberately.

5

5. Open representative items

Enter Workbench from several typical, boundary, and outlier cards. Confirm the issue against the current item, annotations, timeline where applicable, Instructions, ontology, and stage.

6

6. Route the correction

Correct item-level errors through the configured workflow. Create an Issue or change Instructions, ontology, workflow, model mapping, grouping, or source preparation when the pattern is systemic.

7

7. Re-check the same cohort

Apply the original filter criteria again and verify the affected population—not only the example that exposed the problem.

Production QA cohorts

Cohort	Review focus
New or Processing	Attachment completeness, grouping, unreadable sources, and processing failures.
In annotation	Missing coverage, policy ambiguity, assignment imbalance, and operator questions.
In Review or Rejected	Repeated error categories, reviewer consistency, and rework turnaround.
Invalid	Whether the reason is source quality, unsupported format, policy, or incorrect routing.
Complete	Release eligibility, required values, class distribution, and downstream contract readiness.
Recently changed	Effect of a new ontology, Instructions revision, workflow route, model version, or source cohort.

Do not use the workspace Data Space embedding screenshot or filters as evidence for project QA. The project view is authoritative for attached Data Units and project workflow state.

---

Related Unitlab capability guides: Unitlab’s data annotation platform · Unitlab’s data curation platform