Where signals come from

Nora watches your Agent from several angles. There are seven signal types, A through G, and they appear under the same codes in the Source column and filter of the signals list. Every type lands as a candidate — nothing is auto-confirmed. A person confirms or excludes each row (see Confirming failures).

The seven types

Code	Type	What it catches
A · Verifier	`verifier`	The answer contradicts its sources, or asserts something the sources never say
B · Causal	`causal`	An answer’s causal claim conflicts with the causal graph. Opt-in
C · Human	`human`	Someone left negative feedback — a run 👎, a step 👎, or a “not grounded” flag on a specific sentence. Author (end user vs operator) isn’t split
D · Behavioral	`behavioral`	Same session repeats the same question, or contains a correction / complaint pattern that an LLM judge confirms. Opt-in
E · Tool use	`tool_use`	The agent used its tools wrong — three sub-modes below
F · Guardrail	`guardrail`	A guardrail rule blocked the AI’s final answer at the end of the run
G · Canary	`canary`	A capability you disabled has come back to life. Not a failure — a “unblock?” suggestion routed through the rollback flow

E · Tool use — three sub-modes

Emitted from runtime_signals when the agent’s tool sequence went wrong.

`failure_mode`	Meaning
`tool_miss`	A tool the node declared as required wasn’t called
`tool_misuse`	The tool returned an argument / schema error (bad input shape)
`infinite_loop`	The same tool was called successfully N times in a row (default 5) with identical or empty results — the agent was spinning

Error calls don’t count toward the loop threshold — those are either a tool_misuse (bad args) or an environment fault (shows up on the trace, not as a signal).

F · Guardrail block — how confirmation splits

Guardrail signals need a person to say whether the block was correct. The confirm form gives you two choices:

정상 차단 (correct block) — the AI did say something it shouldn’t have. Confirmed → cluster → case.
오발 (misfire) — the answer was fine. Excluded with reason guardrail_misfire, and the row links to the rule so you can tune it.

The blocked answer text is preserved on the signal payload (never in the run output or session memory) so you can review it here.

What’s not a signal

The following used to show up in the queue but are handled elsewhere now:

Not a signal	Where it lives instead
Tool timeouts, 5xx, network faults	Trace errors
Token or cost cap stopped the run	Trace errors
Latency / spend outliers	Simulation cost & latency comparison
SDK ingest went silent	`/signals/sdk-health` health widget
Evaluation regressions	Simulation gate + case `data.fragile`
PII / banned-word matches	Audit log (the block itself still fires)
App-reported outcomes from SDK	Send as a `dislike` on `nora.feedback` instead — `signals.report` is gone

Turning detection on and off

In Settings → Loop, the automation agents section has toggles for Failure detection and verification automation. There is no per-type switch — B (Causal) and D (Behavioral) are opt-in at the agent level.

Signals and traces

Every signal links back to a trace. Press View trace → in the detail drawer to open the exact run that produced it. Traces with a live signal are protected from deletion (see Overview).

Get started

Build

Operate

Settings

Where signals come from

The seven types

E · Tool use — three sub-modes

F · Guardrail block — how confirmation splits

What’s not a signal

Turning detection on and off

Signals and traces

​The seven types

​E · Tool use — three sub-modes

​F · Guardrail block — how confirmation splits

​What’s not a signal

​Turning detection on and off

​Signals and traces

The seven types

E · Tool use — three sub-modes

F · Guardrail block — how confirmation splits

What’s not a signal

Turning detection on and off

Signals and traces