> 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/validation-and-conditional-logic.md).

# Validation and conditional logic

Validation defines whether a supplied value satisfies the data contract. Conditional logic controls when a question is relevant. **Required** is separate: a value may be required and also subject to a type-aware constraint.

### Configure a selected property

![Selected ontology property with Required, Dynamic, default, validation, help text, and dependency controls](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2FlXf333HEHEVKy8p3tnXJ%2Fontology-property-validation.png?alt=media\&token=2a5bb77e-666a-47b9-9d72-e41e0cbbe92d)

*Select a property in the schema canvas to configure its identity and additional settings in the right inspector.*

1. Open the ontology and select the class.
2. Select the property card in the schema canvas.
3. In **Selected property**, confirm the property name, description, and stable ID.
4. Enable **Required** only when an absent value makes the annotation incomplete.
5. Enable **Dynamic** at property creation for supported video or medical time-varying states.
6. Set a default only when it is semantically true for new annotations; a convenience default can silently bias labels.
7. Open **Validation** and choose the rule appropriate to the scalar type.
8. Add **Help text** that explains the accepted form or boundary to the annotator.
9. Review **Depends on** when the property is conditional.

### Type-aware validation

| Property value           | Compact validation supported by the current contract       |
| ------------------------ | ---------------------------------------------------------- |
| String                   | Length or regular expression.                              |
| Number                   | Numeric range or regular expression.                       |
| Date or datetime         | Allowed date/time range.                                   |
| URL, email, or object ID | Regular expression appropriate to the identifier contract. |
| Multiple choice          | Minimum or maximum selection count.                        |

Single-choice properties already constrain the value to one configured option. Keep Required state, controlled options, and any available type-specific validation conceptually separate.

### Create conditional questions

![Conditional ontology tree with Bottle, Glass, and color branches](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2F5WGTh7i4QrEJfLGt2ZjV%2Fontology-nested-properties.png?alt=media\&token=03c67080-6bdb-4616-a711-8e3b8a50b5e8)

*The schema canvas keeps each WHEN condition next to the option that reveals its child property, including deeper nested branches.*

The illustrated logic can be read as:

1. Ask the parent property.
2. If **Bottle** is selected, reveal the child material property.
3. If **Glass** is selected, reveal the nested glass-color property.
4. Otherwise, do not ask the irrelevant child question.

To add the branch, create the parent choice property and its options, add the child property beneath the relevant option, then continue nesting only where another answer changes what must be collected. Use **View Logic Map** before publication to confirm all branches are reachable and named clearly.

### What happens when a value is invalid

Unitlab keeps invalid values visible rather than silently replacing them. The operator receives a message, the value remains in annotation history, and the item can surface through the project's **Invalid** path or QA cohort. Correct the value when evidence supports a valid answer; otherwise use the configured issue, escalation, invalid-data, or rework route.

{% hint style="warning" %}
Do not invent a value merely to clear validation. Add Unknown or Not applicable only when those are legitimate domain values and define how downstream systems interpret them.
{% endhint %}

### Acceptance test for validation and logic

* enter values at, below, and above every boundary;
* test valid and invalid string formats;
* select the minimum and maximum allowed choice counts;
* leave every Required field empty once and confirm the visible invalid state;
* traverse every parent option and verify only relevant children appear;
* test nested branches with keyboard and pointer input;
* inspect the JSON and a sample release so IDs, types, missing values, and nested answers match the downstream contract.