> 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/ontologies/test-an-ontology-in-workbench.md).

# Test an ontology in Workbench

A schema can be structurally valid and still fail the operator. Workbench testing proves that the intended project ontology is actually available, Live, understandable, editable by the correct roles, and compatible with every source modality and release consumer.

### Add the ontology to the project

#### Create or switch a Project Ontology

![Project Ontologies list with a Live ontology](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2FjOjE1y7iPqXilO3mp6Qu%2Fproject-ontologies-current.png?alt=media\&token=1085aad6-b926-4e13-827c-dcecf81bd01d)

*Project Ontologies owns the independent ontology copies used by this project and identifies the single Live selection.*

Open the project and choose **Ontologies**. Use **New Ontology** to create a project-owned schema, or open the row action on an existing copy to make the tested ontology Live. A project can retain several copies for controlled evolution, but annotation uses the Live selection.

#### Import from Global Ontologies

![Global Ontologies catalog inside a project](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2FKIDCx8TOBuPPZZI2OEeI%2Fproject-global-ontologies.png?alt=media\&token=0263d87e-19ce-48cc-86da-90d7363ccef4)

*Importing a Global Ontology creates an independent project copy that can be tested and governed without silently following later catalog changes.*

Choose **Global Ontologies**, find the approved workspace schema, import it, return to Project Ontologies, inspect the copy, and make it Live only after the acceptance test.

### Confirm the ontology in Workbench

![Annotation Workbench Classes panel](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2FXDWBnDB8WFTU6efWwzzN%2Fworkbench-classes-item-properties.png?alt=media\&token=6689950e-874b-493e-bba4-0bc8729fd62f)

*The Classes panel is the operator-facing proof that the project's Live ontology loaded into the native editor. The source canvas, class list, item controls, and workflow action must agree.*

1. Attach a representative dataset version to the project and wait for Project Data to be ready.
2. Open **Project › Data** and enter a representative item in Workbench.
3. Confirm the **Classes** panel contains the expected names, order, colors, geometry icons, required classes, and hotkeys.
4. Create one annotation for every class and supported annotation type.
5. Select an object and set every property; use **Add property** only when the test includes Workbench-side schema authoring.
6. Open **Item properties**, set each static and Dynamic Item Property, and verify the correct item or timeline scope.
7. Create each relation and confirm source, target, direction, and target restrictions.
8. Traverse every conditional branch and trigger every validation error intentionally.
9. Save, route to review, reject or return representative errors, and confirm role-specific visibility and editability.

### Test temporal properties

For video or medical work, use a sequence containing a real state change:

* create a track and set a Dynamic class property at its first authoritative frame;
* move later and change the value;
* expand the object row and verify property ranges and transition points;
* add a Dynamic Item Property, change it later, and confirm it appears as its own timeline row rather than beneath one object;
* adjust a range boundary and verify the intended frames only;
* confirm static properties remain one value across the item.

### Workbench-side schema authoring

Use **Quick Create Class** for a missing compatible class. Use **Manage Classes** to add or configure lightweight classes, Item Properties, and relations. Use **Manage Ontologies** to open the full builder when the change needs advanced types, JSON, Logic Map, version history, or broader review. Changes made during testing are still schema changes and must re-enter the Draft review and publication process.

### Acceptance matrix

| Area                 | Evidence required                                                                                    |
| -------------------- | ---------------------------------------------------------------------------------------------------- |
| Project wiring       | Intended ontology copy is present and the correct one is Live.                                       |
| Classes and geometry | Every class is visible and produces the required native annotation type.                             |
| Properties           | Types, defaults, help text, Required state, Dynamic state, and values behave as designed.            |
| Conditional logic    | Every branch is reachable; irrelevant children stay hidden.                                          |
| Validation           | Invalid input remains visible, understandable, and recoverable.                                      |
| Relations            | Direction and allowed targets are correct in Workbench and output.                                   |
| Item Properties      | Static and dynamic whole-item values use the correct scope.                                          |
| Roles and workflow   | Annotators and reviewers see only valid controls and routes.                                         |
| Downstream contract  | Sample JSON or release output matches field IDs, types, coordinates, relations, and temporal ranges. |

Record each defect with the ontology version, project, source item, role, expected behavior, observed behavior, owner, correction, and retest evidence. Publish only after the acceptance matrix passes.