Skip to main content
A problem is a group of negative signals — emotion, tool failures, laziness, hallucinations — that Moda attributes to a single root cause. New traces are attributed to existing problems within minutes, and new problems are discovered, ranked, and verified automatically as evidence accumulates. Open Observe → Problems to see what is broken, review the evidence, and record what you fixed or dismissed.

What the page shows

  • A Signals section with one card per family — tool failures, frustration, laziness, hallucinations, quality dip — showing negative traces over traces for the window, a sparkline of the selected range against the window before it, and the move in percentage points. One legend names both lines; if the pipeline only has data for part of the previous window, it says where the dashed line starts (for example “30 days before (from Aug 1)”). The diagonal arrow on a card opens that family’s tab on the Signals page. To rank the problems table by a signal, use the sort control’s “By signal” entries.
  • A ranked table grouped by parent. Each group lists the problems the latest rubric parented under it and starts closed, with a chevron to expand; the group row also says how many problems it holds. Leaves with no parent appear as ordinary rows — no Ungrouped folder. Pagination shows 10 groups or ungrouped leaves at a time. Rows show the problem, users impacted, and one signal number — total signals, or that family’s count when the table is ranked by a signal. The sort control and an Open / Fixed state toggle sit above the table. The sort menu offers users impacted, problems per theme, total signals, and one entry per signal family; every entry has its own highest-to-lowest and lowest-to-highest arrows, and the direction is kept in the URL (dir=asc). The time window (1, 7, 30, or 90 days) in the page header applies to the cards and the table together.
The cards count traces the Problems pipeline has finished analysing, so the cards, the coverage figures, and the ranked table all describe the same set.

Lifecycle columns

The Board view has four columns. Column position is computed by Moda — dragging records feedback rather than moving cards directly (see below).

Drag semantics

Dragging a card on the Board submits a feedback action; it never changes the lifecycle immediately:
  • Open or Reopened → Fixed records a mark fixed.
  • Open, Reopened, or Fixed → Resolved records a dismiss. A reason is required before the drop submits.
  • Open and Reopened are not drop targets, and cards cannot be reordered within a column — rank is computed, not user-sorted.
After a legal drop the card stays in its source column with a pending marker until the change is applied. Dropping the same action twice while one is pending is blocked.

Problem detail (Dossier)

Clicking a problem on the ranked list opens its full dossier. The full dossier shows the parent theme above the problem title (when the leaf has one), then Overview and Traces tabs. Overview has impact, a three-stage causal chain (Trigger → Faulty behavior → Observable signals), suggested investigation, and change history. Each stage is a compact card (flag, label, title) joined by a straight arrow. Related problems sit in a collapsed footer on Trigger (“Linked problems”) and Faulty behavior (“Also observed in”); Observable signals has no footer. There is no separate linked-problems list. Stage cards do not open traces. The parent theme is not repeated on the chain. Every problem is referred to by its name (or its cause statement when it has no name yet) on every surface, including merge and split partners in change history; problem ids never appear in the UI. The Traces tab lists traces attributed to this problem. The same list is available through the Data API at GET /problems/:id/conversations. Linked cards under a stage open that problem’s preview. The Dossier header has an icon-only share control (copies the page link) and a menu to rename or dismiss the problem.

Feedback actions

Feedback is how you steer problem discovery. Every action is recorded immediately, shown as pending, and incorporated automatically — nothing edits the problem definition directly.
Feedback is applied asynchronously. Until it is applied, the dashboard shows a pending state on the affected problem, and duplicate submissions of the same action are collapsed onto the pending one.
Feedback can also be submitted through the Data API: POST /problems/:id/feedback.

Next steps

  • Signals — the per-trace detections that problems are built from.
  • Problems in the Data API — read problems, evidence, and reports, and submit feedback programmatically.
  • Analysis — how problems relate to every other computed result.