> 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/end-to-end-quickstart.md).

# End-to-end quickstart

This quickstart is a controlled production rehearsal. Use a small cohort that contains normal cases, edge cases, invalid data, and any grouped or multimodal context required by real work.

### Before you make the change

* Name owners for source data, labeling policy, annotation operations, review, and downstream delivery.
* Prepare a representative sample; do not begin with full production volume.
* Confirm the required roles and an approved destination for the first release.

![Project Data page with attached content](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)

*Project Data is the control point for confirming exactly what entered the work system before annotation starts.*

### Understand the product behavior

**Problem:** The same item appears in four camera views. Treating each recording as an independent task can create inconsistent identity and defect decisions.

**Unitlab pattern:**

1. Ingest the four camera files with consistent identifiers.
2. Use auto-grouping to create one Data Group per inspected item.
3. Arrange four video tiles in a custom layout.
4. Define object classes and defect properties in the ontology.
5. Use tracking or interpolation within each view.
6. Route uncertain cases to a specialist-configured Review stage.
7. Publish a release that preserves the grouped case.

This workflow keeps the four views connected from curation through release, so annotators can make one case-level decision with all relevant visual context available.

### Pattern B: agriculture and repeated objects

**Problem:** A frame contains many similar cherries, and the same scene is captured from two angles.

**Unitlab pattern:**

1. Group the two camera views.
2. Annotate one trusted seed object.
3. Run Find Similar.
4. Adjust the confidence threshold and inspect candidates.
5. Accept only valid suggestions.
6. Continue tracking across frames if the data is video.

This workflow combines multiview context with seed-based assistance, reducing repetitive drawing while keeping acceptance under annotator control.

### Pattern C: medical study with contextual documentation

**Problem:** A finding must be understood across axial, sagittal, coronal, and 3D views, while a clinical document provides case context.

**Unitlab pattern:**

1. Upload or import the medical study and document.
2. Preserve study identity through grouping.
3. Use a custom layout with synchronized medical views and the document.
4. Annotate anatomy with geometry.
5. Record findings through conditional ontology properties.
6. Route the task through specialist review.
7. Export a controlled release after de-identification and governance checks.

This workflow keeps medical volumes and contextual documents together, allowing the specialist to review the case across synchronized views before release.

### Pattern D: customer interaction across text and audio

**Problem:** A written record contains entities and relations, while audio contains speakers, motion, noise, or transcription evidence.

**Unitlab pattern:**

1. Group the text/document and audio as one case.
2. Place them in a joint layout.
3. Annotate text entities and relations.
4. Mark audio event ranges or review a transcript.
5. Use item-level properties for case outcome or escalation status.
6. Validate completeness across both modalities before release.

This workflow preserves the relationship between written structure and temporal audio evidence within one task.

### Pattern E: model-assisted construction safety review

**Problem:** Many people must be tracked over time and classified by helmet status.

**Unitlab pattern:**

1. Use a Person class with a dynamic Helmet status property.
2. Seed or import initial detections.
3. Use Auto-Tracking across later frames.
4. Correct identity drift and status changes at keyframes.
5. Route to review; rejected tracks return to annotation.
6. Measure accepted tracks after rework, not raw predictions.

This workflow combines persistent tracks with properties that can change over time, allowing reviewers to distinguish identity errors from attribute changes.

### Run the first production cycle

{% stepper %}
{% step %}

#### 1. Ingest representative data

Upload or connect the source and wait for server-side processing to finish.
{% endstep %}

{% step %}

#### 2. Preserve context

Create Data Groups and a custom layout when related files must be seen together.
{% endstep %}

{% step %}

#### 3. Publish the contract

Align Instructions and ontology on classes, geometry, properties, ambiguity, and invalid-data rules.
{% endstep %}

{% step %}

#### 4. Build the operating path

Configure workflow stages, queues, assignment, review, rework, and escalation.
{% endstep %}

{% step %}

#### 5. Calibrate the team

Annotate and review the same hard examples until decisions are consistent.
{% endstep %}

{% step %}

#### 6. Deliver one release

Freeze the approved content, export it, and validate it in the downstream consumer.
{% endstep %}
{% endstepper %}

### Decisions that affect production

| Decision           | Production guidance                                                                    |
| ------------------ | -------------------------------------------------------------------------------------- |
| Pilot cohort       | Include representative failure and ambiguity cases, not only clean examples.           |
| Ontology state     | Test in Workbench before making the schema Live.                                       |
| Workflow exit      | Every accepted, rejected, invalid, failed, and escalated item needs a route and owner. |
| Release acceptance | The downstream consumer—not only the Unitlab UI—must validate the result.              |

{% hint style="warning" %}
Do not scale the pilot until the team can reproduce the same decision on hard examples and one release has passed downstream validation.
{% endhint %}

### Continue the operating flow

* Document the approved object model and ownership.
* Complete the Production-readiness review.
* Then expand source volume in controlled batches.