> 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-instructions.md).

# Project Instructions

Write the operational labeling policy visible inside work.

Instructions explain how experts should apply the ontology to real cases. They should resolve inclusion, exclusion, ambiguity, geometry, attributes, invalid data, review, and escalation with representative examples.

### Before you make the change

* Name the policy owner and reviewer.
* Collect representative easy, difficult, ambiguous, and invalid examples.
* Compare every instruction to the ontology and workflow so no route or required value is missing.

![Project Instructions editor](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2F7jrWucEnNWPZV4fEMw0U%2Fproject-instructions.png?alt=media\&token=e5e4c58c-37e3-40d0-aaa8-47c01abb94cd)

*Instructions belong inside the project so annotators and reviewers can consult the current policy without leaving the work context.*

### Understand the product behavior

Instructions can contain:

* rich text/description;
* external URL;
* file attachment;
* PDF upload;
* PPT upload.

Instructions should be the current operational standard an annotator can consult while working. They should include definitions, decision rules, hard examples, counterexamples, uncertainty policy, and escalation steps.

### Publish an actionable policy

{% stepper %}
{% step %}

#### 1. Define the task

State the unit of work, intended output, and what counts as complete.
{% endstep %}

{% step %}

#### 2. Set inclusion and exclusion rules

Explain boundaries and show representative counterexamples.
{% endstep %}

{% step %}

#### 3. Define geometry and attributes

Describe how to draw, classify, relate, and fill required Item Properties.
{% endstep %}

{% step %}

#### 4. Handle ambiguity and invalid data

Give annotators a route that does not require inventing a label.
{% endstep %}

{% step %}

#### 5. Align review and escalation

State what reviewers accept, reject, return, or escalate.
{% endstep %}

{% step %}

#### 6. Calibrate and revise

Run the same difficult examples across roles and update the policy when disagreement reveals a gap.
{% endstep %}
{% endstepper %}

### Decisions that affect production

| Decision          | Production guidance                                                              |
| ----------------- | -------------------------------------------------------------------------------- |
| Example selection | Choose examples that expose the decision boundary, not only ideal annotations.   |
| Ontology coupling | Instructions and schema must change together when policy changes.                |
| Effective date    | Record when a material policy revision begins and how in-flight work is handled. |
| Questions         | Use comments for context and issues for owned correction or follow-through.      |

### Continue the operating flow

* Test the ontology in Workbench.
* Train annotators and reviewers on the same calibration set.
* Record material changes before resuming volume.

***

> **Related Unitlab capability guides:** [AI training-data annotation](https://unitlab.ai/en/data-annotation)