Skip to main content

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.

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:
SettingEffect
Auto-apply thresholdConfidence above which a write happens without review.
Review thresholdBelow auto-apply but above this — queues for review.
Reject thresholdBelow 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.