Signals overview

Signals is the queue of things that might need fixing. When a run executes, the Failure Agent detects problems such as ungrounded claims, tool-use mistakes, and guardrail blocks, then turns them into signals. Human 👎 feedback lands here too. Every signal starts as a candidate. You decide which ones are real failures — only signals you Confirm failure become fix targets and get grouped into a cluster. Signals you mark Not a failure drop out of the counts.

​

Screen layout

The Signals screen has two tabs.

• Failures the list of detected signals. This page covers it.
• Revalidation where accumulated beliefs get re-checked against a reference. See Revalidation.

The top right shows the total count (N signals).

​

The Failures list

The columns: You can filter above the list.

• Search filters by summary text as you type.
• Source filter All sources, or one of the A–G types
• Flow filter All flows, or a specific flow

​

Working the queue

Click a row to open the detail drawer. Review the overview, detection evidence, and any human comment, then press [Confirm failure] or [Not a failure]. See Confirming failures. Confirmation is background: the drawer flips immediately and the cluster + case are created out-of-band. The signal row updates its verdict and cluster columns without a page refresh. Clusters are a separate menu in the sidebar; see Clusters.

​

Traces attached to signals

A trace with a live signal (candidate or confirmed) is protected from deletion — deleting it would erase the evidence the queue points to. The trace list and the builder’s run list surface a confirmation dialog when this happens; the delete only proceeds if you accept.

​

Next steps