> 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/projects/project-data.md).

# Project data

Project Data is the operational view of what entered the project and where it sits in the work lifecycle. Use it to catch source, grouping, filter, status, and rendering problems before they become assignment or quality problems.

### Before you make the change

* Know the expected dataset version and item count.
* Define representative normal, edge, grouped, and invalid examples.
* Confirm the intended workflow start state.

![Project Data view with filters and items](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2FsJhHsK7YkhabBtix4o95%2Fproject-data.png?alt=media\&token=06bd10a9-5d5a-4680-a807-d0fc697c37ac)

*Use Project Data to reconcile source membership, Data Unit state, and the item population seen by annotators and reviewers.*

### Understand the product behavior

The project’s default Data page offers three URL-persisted views:

* **Grid** — dataset/source cards above item cards;
* **List** — dataset table at the root and annotation-oriented item table inside a dataset;
* **Embedding** — visual embedding scatter plus the filtered item grid.

At the root, attached datasets display their frozen version in the name, and the project’s own uploads appear as one dataset card named after the project. **View Source** and **Detach** are available from the source-card menu.

Inside a dataset, List view shows item Name, Type, workflow Status, Assigned to, and Priority. A Data Group appears as an expandable parent row whose children are indented tiles; the parent carries the group’s workflow status, assignee, priority, labeled progress, and grouped-Workbench link.

The toolbar includes Upload Data, Attach Data, search, Grid/List/Embedding view controls where applicable, card-size control, filters, and selection actions. Text and audio contexts can hide the visual embedding toggle.

### Project filter presets

Advanced Filters can be saved as private, user-scoped project presets. Supported conditions include status, annotators, reviewers, classes, issues, properties, item properties, and tags, using is-any-of or is-none-of logic. A preset can contain up to 20 conditions. Presets are personal UI state rather than auditable project data, so deleting one removes it immediately without changing project content.

### Project data QA and visual inspection

The project Datasets page is also a quality-inspection surface. It combines workflow filters, assignment filters, semantic filters, card-density controls, and annotation-aware display settings so a manager or reviewer can find a problematic cohort and inspect it consistently before opening individual items.

**QA entry points**

| Control                                  | What it helps the user inspect                                                               |
| ---------------------------------------- | -------------------------------------------------------------------------------------------- |
| Workflow stage and status                | New, in-annotation, in-review, processing, complete, archived, error, and invalid cohorts    |
| Assigned                                 | Work owned by a particular annotator or reviewer, or work that remains unassigned            |
| Classes, properties, and Item Properties | Items containing selected ontology content or missing the expected semantic coverage         |
| Issues and tags                          | Known exceptions, escalations, and project-specific quality categories                       |
| Search and Advanced Filters              | A precise subset defined by file, workflow, ontology, assignment, or saved-preset conditions |
| Grid, List, and Embedding views          | Visual inspection, operational table review, or distribution/outlier exploration             |
| Card-size slider                         | More items for rapid scanning or larger cards for closer visual inspection                   |
| Display View                             | Annotation-rendering controls applied consistently across the visible cards                  |

The **Display View** panel contains:

* **Show object names** — renders class/object names on the visible annotations;
* **Color by object ID** — assigns visual identity by instance rather than only by class, which is useful for distinguishing nearby or overlapping objects;
* **Crop view** — focuses each card on its annotated region when close inspection matters more than full-image context;
* **Additional zoom** — increases the inspection scale inside the crop;
* **Boundary thickness** — adjusts annotation-edge thickness;
* **Border opacity**, **Vector opacity**, and **Mask opacity** — independently control the visibility of outlines, vector geometries, and filled masks;
* **Classes** — searchable per-class visibility controls, with expandable **Properties** and **Attributes** visibility where those structures exist.

These are visual QA controls. They do not modify annotation geometry, ontology values, workflow state, or source media. Advanced Filters determine which items are in the result set; Display View determines how their annotations are rendered for inspection.

**Visual QA flow**

1. Open a project dataset and define the cohort with search, status, assignment, class/property, issue, tag, or saved-filter conditions.
2. Choose Grid for visual scanning, List for operational comparison, or Embedding for distribution and outlier inspection.
3. Adjust card size to balance cohort coverage against image detail.
4. Open **Display View** and enable the object names, object-ID coloring, crop, zoom, boundary, and opacity settings needed for the annotation type under review.
5. Search or isolate classes and, when necessary, expand their properties or attributes to remove unrelated overlays.
6. Inspect the visible cohort, then open a questionable item in the Workbench without losing the surrounding project context.
7. Use a comment for item-specific discussion, create or update an issue when ownership and follow-through are required, or use the current Review-stage action to approve or return the item for correction.

This flow supports cohort-first QA: the reviewer can first identify a repeated pattern across many items, then move into the exact annotation context where a correction or workflow decision is made.

### Qualify project data before assignment

{% stepper %}
{% step %}

#### 1. Reconcile attachments

Confirm every dataset card, version, source link, and detach control.
{% endstep %}

{% step %}

#### 2. Compare counts

Match expected source membership to created Data Units and grouped behavior.
{% endstep %}

{% step %}

#### 3. Use filters deliberately

Inspect status, source, modality, assignment, or saved preset cohorts.
{% endstep %}

{% step %}

#### 4. Switch visual modes

Use Grid, List, Embedding, and Display View according to the QA question.
{% endstep %}

{% step %}

#### 5. Open the native editor

Confirm representative items load the right Workbench, ontology, layout, and stage actions.
{% endstep %}

{% step %}

#### 6. Resolve exceptions

Correct invalid, failed, duplicate, ungrouped, or unreadable content before assignment.
{% endstep %}
{% endstepper %}

### Decisions that affect production

| Decision        | Production guidance                                                                       |
| --------------- | ----------------------------------------------------------------------------------------- |
| Count mismatch  | Stop and reconcile attachment, grouping, filters, duplicates, and processing failures.    |
| Saved preset    | Use for repeat operational views; document the underlying criteria for shared procedures. |
| Bad source item | Decide whether to correct, replace, mark invalid, archive, or route around it.            |
| Detach          | Review active work and downstream dependencies first.                                     |

### Continue the operating flow

* Publish Instructions and ontology.
* Test every modality and layout used by the project.
* Open queues only after the work population is approved.