> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getclaro.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Notifications

> The review queue for every operation that needs human approval.

Every operation that produces a below-threshold change lands here. Notifications is the single place where reviewers approve, reject, or edit pending writes — for any catalogue, any operation, any data source.

***

## How items get here

Three settings govern how aggressive each operation is:

| Setting                  | Effect                                                 |
| ------------------------ | ------------------------------------------------------ |
| **Auto-apply threshold** | Confidence above which a write happens without review. |
| **Review threshold**     | Below auto-apply but above this — queues for review.   |
| **Reject threshold**     | Below this — discarded with a logged reason.           |

Defaults are conservative. Per-operation, per-attribute, and per-source overrides are supported (set under the catalogue's Config tab).

A change with confidence in the *review* band is sent to Notifications. A change in the *auto-apply* band is written immediately and shows up in operation history, not in Notifications.

***

## What a review item looks like

Each item shows:

* **The proposed change** — old value, new value, attribute, record.
* **Confidence score** — the 0–100 score and the factors that contributed to it.
* **Provenance** — the operation, run, data source, model, and any cited Knowledge Base passages.
* **Side-by-side context** — for similarity merges, the two records and per-field similarity.
* **Actions** — Approve, Reject, Edit, Skip, Snooze.

Items are grouped by operation and clustered when they share a cause (e.g. all values from the same supplier upload, all merges from a single Find Duplicates run).

***

## Bulk actions

Reviewers rarely act one-by-one. Common patterns:

* **Approve all in this cluster** — one click to accept every change from a single run, optionally filtered by confidence range or attribute.
* **Reject all from this source** — when an upstream supplier file is bad.
* **Edit-then-apply** — fix the value inline; the edited value is recorded with the reviewer as the source.
* **Refine and re-run** — adjust the operation's prompt or thresholds, then re-run on the failing subset.

***

## Reviewer assignment

Each catalogue's Config tab specifies default reviewers. Reviewers can also be assigned per attribute (e.g. legal team for `compliance_*` fields, merch team for category and pricing fields).

Items in your queue are filtered by your role and the attributes you own. An admin view shows everything in the workspace.

***

## What happens after review

* **Approved** — the value is written to the record. Provenance includes both the originating operation and the reviewer.
* **Rejected** — the proposed value is discarded. The reject is logged and (for similarity matches) used as a negative example to refine future matching.
* **Edited** — the reviewer's value is written with the reviewer as the source.

Every action is part of the catalogue's history and is reversible from the record's per-field log.

***

## Notifications vs. alerts

Don't confuse review items (which need a decision) with monitoring alerts (which signal something happened). Monitor → Price and Monitor → Competitor publish alerts to the same surface, but alerts are informational — they link out to the relevant catalogue view rather than waiting on approval. Slack delivery is configurable per alert class.