The result hierarchy
Every Failure Analysis result follows this structure:The FailureSummary
Theresult.summary gives you the big picture at a glance:
Key decision fields
Reading a FailureTag
EachFailureTag 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
Thejudge_rationale field explains exactly what went wrong and why:
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
Useshould_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.