Skip to main content
Knowing that a failure keeps coming back is only half the answer. For every tracked finding marked as a failure, DataFramer reads a sample of its traces and reports the distinct root causes behind it, each cited to the traces it was drawn from, with a suggested fix where the evidence supports one, down to the exact prompt edit. Open a tracked finding to see them. The Root causes & suggested fixes section appears on findings marked as a failure, which Discovery does for you as it groups them.

When analysis runs

With Auto-analyze on, which it is by default, analysis runs by itself the first time a failure is pinned, and again after a refresh that adds enough new traces; it does not run for every new trace. Use Analyze failures & suggest fixes (later Re-analyze) to run it on demand. Each run reads a sample of the finding’s traces, skips traces over the size limit, takes several minutes and draws on AI spend; you can leave the page while it runs. When it finishes, the section shows when it ran, how many traces it sampled, how many new traces arrived since, and what it cost. A run can come back with no causes when nothing clears its confidence bar.

What each root cause holds

Every root cause comes with:
  • Evidence: the traces attributed to the cause, each with the passage that shows it. Since analysis samples, most traces are attributed to no cause; filter the finding’s trace list by Root cause to see the ones that are.
  • Suggested fix: what to change in your application, plus prompt edits as before/after passages when the fix is a prompt change. A cause with no confident fix says so.
  • A status: a cause recent runs no longer find is labeled No longer detected, the signal that a fix worked; it returns by itself if the issue comes back.

From your coding agent

Everything above is readable through the read-only Failures API, so a coding agent such as Claude Code or Cursor can read the causes and apply the suggested prompt edits to your codebase. Connect the agent through MCP; the tools list_failures, get_failure and get_context cover failures. Then ask it, for example: “Read our active failures in DataFramer and apply the suggested prompt edits to our prompts.” The same data through the Python SDK:
Under each failure’s analysis:
  • status, last_analyzed_at and new_traces_since_analysis say whether causes exist and how fresh they are.
  • causes[] are the root causes, each with examples[] as evidence and a remediation holding the instructions and the prompt_template_edits[] as before/after passages.
  • prompt_templates[] are the prompt templates DataFramer reconstructed from your traces; each edit’s template_ref names the one it applies to, so the agent can find the matching text in your repository.
Pass updated_since to read only what changed since the last call. For more grounding than the edit itself, fetch Get context once: the rubrics your traces were graded against and the knowledge distilled from your expert reviews.

Next steps

Reviews

Route the patterns you track to a human reviewer

Failures API

Every field the causes and fixes are served with

API & MCP

Get an API key and connect your coding agent