> 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/collaboration/comments-issues-and-notifications.md).

# Comments, Issues, and notifications

Collaboration tools serve different purposes: Instructions publish policy, comments preserve contextual discussion, Issues create owned follow-through, notifications create awareness, and workflow actions change the task state.

### The operating model

```mermaid
flowchart LR
  A["Policy question"]
  B["Comment"]
  C["Issue with owner"]
  D["Correction or policy change"]
  E["Workflow review"]
  F["Notification"]
  A --> B
  B --> C
  C --> D
  D --> E
  E --> F
```

Comments live inside the annotation workbench and are appropriate for context attached to a specific item or label. They should not become the only place where a repeated rule is documented; recurring decisions belong in the instructions or ontology.

### Issues

Project issues include content, status, responsible member, creator, and created date. Issue links can return the user to the exact annotation context and load the correct editor for that item’s data family. An issue is appropriate when a problem requires ownership and follow-through beyond one annotation comment.

### Review and specialist escalation

Review is an explicit workflow decision. Specialist escalation can be modeled as another Review stage with a restricted eligible-member list. A useful closed loop is:

```
Annotation or policy error
    ↓
Reviewer correction or rejection
    ↓
Issue categorized
    ↓
Ontology, instruction, model, or assignment change
    ↓
New tasks measured for recurrence
```

The most important quality metric is not raw labeling speed. It is accepted, usable units per hour after correction, rework, and downstream failures are included.

### Notifications

Workflow-aware notifications include stage-ready, task-assigned, task-claimed, rework, comment, mention, automation, and conflict events. The notification list supports bulk actions. Rework notifications are particularly important because they connect a reviewer’s rejection to the annotator who must correct it.

### Statistics and team visibility

Statistics appear at project and member levels. Current surfaces include:

* project overview charts;
* monthly progress;
* daily time series;
* overall progress;
* average time per item;
* total working time;
* issue counts;
* annotator and reviewer breakdowns;
* member heatmaps and summaries;
* workspace member statistics pages.

Some statistics and premium role experiences depend on the workspace subscription. Statistics should be interpreted with workflow context—for example, faster annotation can coexist with higher reviewer rejection and should not be reported as improved productivity in isolation.

### Use this in production

* Use comments for item context that helps another person understand the decision.
* Create an Issue when correction, investigation, or policy work needs an owner and status.
* Use workflow review to accept, reject, or escalate the task itself.
* Configure notifications for awareness; do not use notification receipt as proof of ownership.
* Review recurring Issues as signals of source, Instructions, ontology, workflow, or training problems.