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

# Feedback on a trace

> Thumbs, corrections, and notes — added right where the answer went wrong.

The fastest way to improve an Agent is to look at a run and say "no, wrong". The Trace view is where you do that. Every piece of feedback becomes part of the signal loop that drives Improvements.

## Adding feedback

Two entry points:

* The **thumbs bar** on the final answer (👍 / 👎).
* **Right-click** any step in the timeline → **Add feedback**.

Step-level feedback attaches to that specific step (a wrong tool call, a bad retrieval), not the whole run.

## Feedback types

* **👍 / 👎** — quick signal.
* **Text correction** — write what the right answer would have been.
* **Categorization** — tag with a failure type (`hallucination`, `wrong-tool`, `stale-info`, custom tags).
* **Reference correction** — point to the source that has the correct info.

You can combine any of these on a single run. The richer the feedback, the more useful it is downstream.

## What happens after you submit

The feedback becomes a **Signal** immediately (see [Signals overview](/reliable/signals/overview)). What happens next depends on the type:

* **Standalone signal** — a single event, viewable in the Signals queue.
* **Cluster join** — if the failure looks like others, joins an existing cluster.
* **Cluster seed** — if it's a new pattern, seeds a cluster of one that may grow.

Rich feedback (with corrections and tags) leads to better clustering and faster improvements.

## Feedback from users

End users can also give feedback — the Agent's chat UI has a thumbs bar per turn. User feedback lands in Signals the same way.

Anonymous vs. authenticated:

* Chat sessions from signed-in users carry the user's identity.
* Public chat feedback is anonymous by default (only the session ID is retained).

## Bulk feedback

Two workflows for bulk:

* **CSV import** — a spreadsheet with columns `trace_id, verdict, tag, correction`. Upload from Signals.
* **Programmatic** — POST to `POST /traces/{id}/feedback`. Useful for offline review pipelines or Slack-triggered feedback.

## Editing / removing feedback

Feedback is editable for 7 days after submission. Beyond that, feedback is immutable — the audit trail matters more than reversibility. If a signal was based on wrong feedback, mark the signal as `false alarm` (see [Confirm or mute](/reliable/signals/confirm)) rather than deleting.

## Feedback and privacy

Feedback shows the trace author's name (you) unless posted anonymously. Anonymous mode strips identity from downstream views but preserves it in the internal audit log for compliance.

## Recording feedback as an improvement rule

For team-authored feedback, click **Save as rule** to promote the correction into a procedural memory rule (see [Procedural rules](/build/memory/procedural)). The rule applies immediately to future runs — the fix is live before Improvements even needs to run.

Best used for high-confidence corrections where the fix is easy to state ("always mention 'before tax' in price answers"), not for nuanced cases that need proper testing.