---
id: troubleshooting.unclear-cases
title: Unclear Cases
summary: Repair Cases that informed reviewers cannot interpret consistently from the supplied input, context, and output identity.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-08-23
canonical: /docs/troubleshooting/unclear-cases
---

# Unclear Cases

## Symptoms

- Reviewers ask what they are supposed to judge.
- The same Case produces incompatible readings because a source, prior turn, time boundary, or user state is absent.
- A candidate answer is visible, but it is unclear whether it is the judged output or reference behavior.
- The Case title or metadata implies context that the review presentation does not contain.
- Experts can answer only by inventing assumptions.

## Likely causes

- A prior conversation turn, source, time boundary, or user state is missing.
- Candidate and reference outputs are swapped or unlabeled.
- One Case combines multiple situations or requested judgments.
- Important instructions live in metadata or private project knowledge instead of visible context.

## Diagnose the Case, not the reviewer

1. Open the Case in its normal review presentation and read only what the assigned expert can see.
2. Identify the judged input and output separately. For conversations, confirm the turn order and which response is under review.
3. List every fact required to make the judgment, then verify each fact is present as Case content, context, source material, or an explicitly linked standard.
4. Check whether metadata is being used as hidden instruction rather than visible context.
5. Compare reviewer rationale. Repeated invented assumptions usually reveal the missing boundary.

## Fix

- Add or map the missing context when it belongs to the real situation.
- Correct the output attachment when candidate and reference behavior were swapped.
- Split a Case that combines two independently judged situations.
- Narrow the question or applicability boundary when multiple interpretations are legitimate.
- Mark the Case unresolved or keep it as candidate material when authoritative evidence is unavailable.
- Create a new Case version when the reviewable content changes; do not silently rewrite evidence used by an existing Snapshot.

After correction, have a reviewer who did not author the Case explain the situation and requested judgment. If they must rely on private project knowledge, the Case is still incomplete.

## Prevention

Review the Case through the same presentation an expert will see, label output identity explicitly, and include every fact required for judgment. Sample imported and generated Cases before Benchmark selection, and version content changes after evidence exists.

{% example-demo title="Example: recommendation without the user's equipment" %}
A Case asks whether a product is compatible but omits the equipment model mentioned in an earlier conversation turn. Reviewers alternate between pass and fail. The operator restores the prior turn, confirms the candidate output identity, versions the Case, and repeats the affected review. The old Snapshot retains the earlier ambiguous version.
{% /example-demo %}

## Source confidence

Code-backed: Cases, Case review, Contribution preview, and Case-content schemas establish the separate input, contextual-material, and presentation boundaries used here. Whether the supplied facts are sufficient for a domain judgment remains reviewer-owned.

## Related task pages

{% related-card-grid title="Related workflows" %}
- [Case model overview](/docs/assets)
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
- [Boundary Cases](/docs/coverage-engineering/boundary-cases)
- [Case Versioning](/docs/governance/case-versioning)
{% /related-card-grid %}

## Related reference pages

{% related-card-grid title="Related reference" %}
- [Cases](/docs/object-model/cases)
- [Represent conversations in Cases](/docs/object-model/represent-conversations-in-cases)
- [Metadata and context](/docs/reference/metadata-and-context)
{% /related-card-grid %}