> 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/get-started/the-unitlab-object-model.md).

# The Unitlab object model

Most production mistakes begin by using the right capability at the wrong layer—for example, treating a folder as a dataset version or treating a project task as durable source data.

### The operating model

```mermaid
flowchart LR
  A["Asset"]
  B["Data Group"]
  C["Dataset version"]
  D["Project Data Unit"]
  E["Workflow task"]
  F["Release item"]
  A --> B
  A --> C
  B --> C
  C --> D
  D --> E
  E --> F
```

Several platform terms sound similar but serve different purposes. Keeping them distinct makes product explanations much clearer.

| Object          | Purpose                                                                                            | What changes over time                                                   |
| --------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| **Asset**       | A source file or data item stored in or connected to Data Space                                    | Metadata, tags, folder placement, and curation state                     |
| **Folder**      | A source-oriented container for assets; it can also represent a cloud-backed location              | Contents, synchronization state, subfolders, and grouping                |
| **Data Group**  | A related set of files treated as one multimodal or multiview unit                                 | Group membership and tile layout                                         |
| **Dataset**     | A curated working collection assembled from folders or individual assets                           | Unpublished changes and explicit published versions                      |
| **Project**     | The operational environment where data is annotated and reviewed                                   | Attached sources, ontology copy, tasks, annotations, and status          |
| **Ontology**    | The reusable schema defining objects, properties, classifications, events, entities, and relations | Working edits, Live versions, nested logic, and project-specific history |
| **Workflow**    | The routing graph for Project, Annotate, Review, Model, Archive, and Complete stages               | Stage topology, assignments, and accepted/rejected paths                 |
| **Task**        | A workflow unit assigned to a person or made available to a queue                                  | Assignee, priority, state, review decision, and timeline                 |
| **Batch Queue** | A processing batch for uploaded or imported project data                                           | Processing, completion, and failure counts                               |
| **Release**     | A versioned annotation snapshot prepared for downstream use                                        | Version, split, export, annotation package, and associated files         |
| **AI model**    | A public or private model connected to annotation or workflow operations                           | Endpoint/configuration, validation, class mapping, and running state     |

### Data Units in the SDK

The SDK makes one additional distinction:

* A loose file becomes a `datasource` Data Unit.
* A Data Group becomes one `group` Data Unit whose `items` contain its tile summaries.
* Group member files are not duplicated as separate top-level project units.

This is an important design detail for multimodal cases. A four-camera inspection, a DICOM study with related views, or a video–document–audio case can remain one unit of work rather than four unrelated tasks.

### Use this in production

* Use folders for organization, datasets for reusable membership, and releases for delivery.
* Use Data Groups when multiple files must remain one work unit.
* Use stable resource IDs and explicit versions in automation and audit records.