Skip to main content
In the previous page, you ran Failure Analysis on a sample dataset and saw a hallucination detected. Now let’s understand the result in detail and fix the issue.

The result hierarchy

Every Failure Analysis result follows this structure:

The FailureSummary

The result.summary gives you the big picture at a glance:

Key decision fields


Reading a FailureTag

Each FailureTag represents one classification decision for one item:

Understanding severity

Understanding confidence

  • 0.9–1.0: The judge is highly certain about this classification.
  • 0.6–0.9: Likely correct but some ambiguity exists.
  • Below 0.6: The judge is uncertain — consider human review. These often come with decision: "unsure".

Root cause analysis

The judge_rationale field explains exactly what went wrong and why:
The scoring_breakdown provides structured evidence:

Fix the prompt and re-run

Now that you know the root cause, fix the issue. In this quickstart example, the “fix” is simply providing the correct output — but in real applications, you’d adjust your prompt, retrieval pipeline, or guardrails.

Before (failing)

After (fixed)

Re-run to confirm

When failures drop to zero, your fix is confirmed. In a real workflow, you’d commit the prompt change and add this as a regression test.

Filtering failures programmatically

For larger datasets, filter and sort failures by severity:

CI/CD gating

Use should_gate_ci to block deployments when critical failures are found:

How Valiqor works →

Understand the architecture, config resolution, and async behaviour.

Full FA workflow →

Advanced options: custom buckets, trace mode, async runs, and more.