> ## Documentation Index > Fetch the complete documentation index at: https://docs.moda.dev/llms.txt > Use this file to discover all available pages before exploring further. # Signals > Per-conversation detections — user emotion, tool failures, laziness, and hallucinations — with KPIs, taxonomies, and evidence links. A signal is an automatic per-conversation detection: expressed user emotion, a failed tool call, an effort shortfall, or a claim contradicted by recorded execution state. The Signals page (sidebar: Observe → Signals) is where you browse them. Detections typically appear within minutes of ingest. ## Page controls * **Date range** — Last 24 hours, 3, 7, 14, 30, or 90 days, or a custom range. * **Refresh** — reloads the active tab. * **Tabs** — Overview, Browse, User Emotion, Tool Failures, Laziness, Hallucinations. The active tab is addressable via the `type` URL parameter (`overview`, `browse`, `emotion`, `tool-failures`, `laziness`, `hallucinations`), and each detector tab supports its own deep-link parameter: `tool` (Tool Failures), `family` (User Emotion), `pattern` (Laziness), and `rule` (Hallucinations). ## Overview Cross-detector KPI cards, each with the counts behind the rate, the change against the previous window, and a link to the matching tab: | Card | Rate | | --------------------- | ------------------------------------------------------------------------- | | Negative emotion rate | Conversations with a negative-emotion detection / analyzed conversations. | | Tool failure rate | Failed tool calls / all tool calls. | | Lazy response rate | Conversations flagged for laziness / active conversations. | | Ungrounded claim rate | Unverified scored messages / all scored messages. | Below the cards, **What is changing** lists detector patterns that are moving against the previous window, and **Where conversations are concentrated** shows the top use cases with a **Browse use cases** link to [Use Cases](/dashboard/use-cases). ## Browse **Signal inventory** — one row per detector pattern (an emotion signal, a failing tool, a hallucination rule, a laziness family) with columns: | Column | Shows | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Pattern | The pattern name and a one-line description. | | Signal | The detector it belongs to: User emotion, Tool failure, Laziness, or Grounding. | | Reach | Detections or affected conversations in the window. | | Share | The pattern's share of its detector's window total (analyzed conversations, scored messages, or headline detections, depending on the detector); shown as — where no share applies, including tool failures. | Rows can be searched, filtered by signal type, and opened into an evidence slideout. ## User Emotion Detects emotion expressed in the user's own messages, classified into 6 families and 16 signals. Every analyzed conversation counts toward the KPIs; the table lists conversations with at least one detection or a negative-family risk score of 0.5 or higher. KPIs: | KPI | Meaning | | ------------- | ----------------------------------------------------------------------------------------------------- | | Analyzed | Conversations that completed emotion analysis in the window. | | Negative Rate | Share of analyzed conversations with at least one negative-family detection. | | At Risk | Conversations with no confirmed negative detection but a negative-family risk score of 0.5 or higher. | | Repair Rate | Share of negative detections whose trajectory ended resolved. | Rows carry a status of Detected, At Risk, or Positive. Filter by status (All statuses / Detected only / At risk only), family, elicitor, and trajectory; sort by Highest score, Lowest score, Highest risk, Most recent, Oldest first, or Most messages; search by conversation ID or cause. Opening a row shows the cause, trajectory, elicitor, and verbatim user quotes — each quote links into the conversation's [Full Trace](/dashboard/conversations) at the quoted turn. ### Emotion taxonomy | Family | Signals | Polarity | | ----------- | ------------------------------------------------------------------------------- | -------- | | Frustration | `exasperation`, `anger`, `profanity`, `insult`, `sarcasm`, `escalation_request` | Negative | | Sadness | `disappointment`, `resignation`, `self_blame`, `personal_distress` | Negative | | Confusion | `confusion` | Negative | | Anxiety | `urgency` | Negative | | Trust | `distrust` | Negative | | Positive | `gratitude`, `satisfaction`, `delight` | Positive | Each detection also records: * **Elicitor** — what elicited the emotion: `bot`, `external`, `self`, or `ambiguous`. * **Trajectory** — how it evolved across the conversation: `none`, `building`, `peak`, `resolved`, or `sustained`. * **Score and risk score**, a primary cause, and supporting quotes. ## Tool Failures "Tool invocations that returned errors or failed to execute." Every tool call is recorded at ingest, so failures appear quickly; failed calls are then grouped into named failure categories per tool. KPIs: **Failed Conversations**, **Total Failures**, **Failure Rate**, **Users Impacted**, **Tools Impacted**. A time-series chart plots failure events (stacked or grouped), and a per-tool drill-down is deep-linkable with `?tool=`. Each failure category carries: | Field | Meaning | | ------------------ | ---------------------------------------------------- | | Category label | Short name for this kind of failure. | | Family | The broader failure family the category belongs to. | | General error | A description of the underlying error. | | Likely cause | The probable cause of the failures in this category. | | Recommended action | A suggested fix. | Individual failure events link into the conversation at the failed call. Tool-level success rates and usage live on the [Tool Catalog page](/dashboard/users-and-tools). ## Laziness "Agent effort shortfalls — skipped tools, stubs, and under-delivery." Detections come from deterministic response patterns. Ingest-truncation artifacts are listed but excluded from headline counts. KPIs: **Detections**, **Conversations Affected**, **High-Confidence Share**, **Patterns Firing**. Detections with confidence 0.5 or higher count as laziness on their own ("high-confidence"). Weaker detections are corroborating only — they count when at least two pattern families co-occur in the same conversation. Filter by pattern family (`?pattern=`) and status (All conversations / High-confidence only). ### Pattern families | Family | What it flags | | ----------------------- | ------------------------------------------------------------------------------------------------------------ | | Omitted code (comment) | A code comment stands in for content the agent should have written out (for example "... rest of code ..."). | | Omitted code (phrase) | Prose like "rest of the code remains the same" in place of the actual code. | | Stubbed implementation | A placeholder body (raise NotImplementedError, TODO: implement) instead of working code. | | Refusal opener | The reply opens with an apology or inability preamble on an in-scope coding task. | | Deflected to the user | Points the user at the docs or "implement it yourself" instead of doing the task. | | Truncated data (ingest) | An ingest/logging artifact, not agent behavior — excluded from headline laziness counts. | | Promised, not delivered | The final message promises an action but no tool call ever follows it. | | "Can't from here" | Claims the action can't be done "from here / this chat", cross-checked against your tool catalog. | | Claimed inability | Says it can't perform an action (send, edit, access) its tool catalog suggests it can. | | Admitted a mistake | Acknowledges wrong or stale inputs — a lagging marker that flags the conversation for review. | | Irreversible slip | States the action already went out and can't be pulled back. | | Stalling | Asks to wait and re-check later instead of making progress (weak on its own). | | Do-it-yourself handoff | Hands the final step back to the user ("paste this...", "from your own inbox"). | When present, judge-verified detections appear as two additional families — **Tool selection (judged)**, where the agent skipped or misused a tool the task required, and **Under-delivery (judged)**, where the agent delivered less than the user asked for. Each carries a subtype: Missing tool call, Wrong tool, Missing required call, Excess tool call, or Under-delivery. ## Hallucinations "Agent claims checked against recorded execution state." Claims in agent messages are checked against the tool receipts and task state recorded in the conversation's world state, so checks run once the world state is built — minutes after ingest. The tab carries a banner: detections are rule/model generated and not yet used for alerting. KPIs: **Contradicted**, **Verified Claims**, **Unverified Rate** (unverified share of scored messages), **Messages Analyzed**. ### Verdict semantics Each scored agent message gets at most one verdict — the most severe claim in the message wins: * **Contradicted** — a claim conflicts with recorded evidence. Listed per message with the claim quote, the rule that fired, and the evidence it violates. * **Verified** — a claim is confirmed by a matching successful tool receipt. Listed per message. * **Unverified** — a claim could not be checked either way. Counted only in aggregates (the Unverified Rate); never listed per message. Per-message and per-conversation lists therefore show only contradictions and verified claims. The same policy applies to the [Data API hallucinations endpoint](/data-api/signals). ### Rules Rule chips above the list filter by rule (`?rule=` deep link): | Rule | Fires when | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | `success_vs_error_receipt` | The message claims an action succeeded, but the matching tool receipt recorded an explicit error. | | `completion_vs_failing_check` | The message claims work is complete (tests, build, typecheck, lint, deploy) while the latest matching check receipt failed. | | `count_mismatch` | A count stated in the message does not match the counts recorded in tool output. | | `false_absence` | The message claims nothing exists or nothing was found, while a matching receipt recorded non-trivial output. | | `thread_status_contradiction` | The message contradicts the recorded status of a task thread. | | `receipt_verified` | A claim is confirmed by a matching successful receipt — this produces a verified claim, not a contradiction. | Filter conversations by status (With contradictions / All scored conversations), sort by Most contradictions, Most verified, Most recent, or Oldest first, and search by conversation ID. Expanding a conversation lists each detection with its message number, offending quote, and the rule that fired; the conversation ID links into the conversation. ## Next steps * [Problems](/dashboard/problems) — signals grouped by root cause and ranked by impact. * [Home](/dashboard/overview) — the same quality rates as at-a-glance KPIs. * [Conversations](/dashboard/conversations) — where every signal's evidence links land. * [Data API: signals](/data-api/signals) — query emotions, tool failures, and hallucinations programmatically.