# Maintain reusable Cases across benchmarks
Generated: 2026-11-13T08:01:27.677Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: workflow.assets.reuse-cases
title: Maintain reusable Cases across benchmarks
summary: Reuse project Cases while keeping benchmark membership and frozen assessment populations distinct.
kind: task
product_area: assets
status: stable
updated: 2026-11-11
canonical: /docs/assets/reuse-cases
---
# Maintain reusable Cases across benchmarks
Reuse project Cases while keeping benchmark membership and frozen assessment populations distinct.
## Prerequisites
Access to the Project Case and each benchmark you intend to change.
## Steps
1. Inspect the canonical input, materials, and classifications before selecting a Case for another benchmark.
2. Use the benchmark’s dataset selection workflow to include the relevant Case. Check why it belongs in that benchmark’s intended population.
3. Review representation and applicable standards for the receiving benchmark.
4. Create a new Snapshot when the changed population needs to become a fixed assessment boundary. Compare against the intended Benchmark Version.
## Object and state changes
The Project owns the reusable Case. Each benchmark owns its selected membership; existing Snapshots and accepted Runs retain their recorded inputs.
## Success criteria
The same useful situation can support several benchmarks without hiding which population each result measured.
## Common failure modes
Assuming Case existence implies dataset membership; treating an old Snapshot as if it contained a later edit.
## Related reference pages
{% related-card-grid title="Continue this workflow" %}
- [Understand Case inputs and materials](/docs/assets/cases)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Resolve a problem" %}
- [Unclear Cases](/docs/troubleshooting/unclear-cases)
- [Synthetic Cases That Feel Unrealistic](/docs/troubleshooting/unrealistic-synthetic-cases)
{% /related-card-grid %}
---
id: assets.cases
title: Understand Case inputs and materials
summary: Understand canonical project cases, their input and materials, and how they become members of benchmark datasets.
kind: reference
product_area: assets
status: stable
updated: 2026-11-11
canonical: /docs/assets/cases
---
# Understand Case inputs and materials
## Definition
A Case is a project-level situation used for expert contribution, benchmark coverage, or candidate evaluation. It has canonical input content and may include declared supporting materials. Cases live in the Assets pool and can be selected into one or more benchmark datasets.
The Project Input Schema determines how the primary input and materials are represented. A benchmark snapshot determines which selected cases belong to one versioned snapshot boundary.
## Fields, states, or lifecycle rules
- Canonical primary input is stored under `content.input`.
- Optional supporting values or artifacts are stored under `content.case_materials` according to the project's declared keys.
- `record_content.case_view` is a rendered projection used for inspection and delivery; it is not a second editable payload.
- Inputs can use plain-text, chat, or structured architecture as configured by the project.
- Materials can include admitted artifact families and must satisfy any required-field and file-extension rules.
- A project Case is not automatically part of every benchmark. Benchmark Datasets owns selection and snapshots.
- Generated or imported Cases should be reviewed for clarity, source authority, and schema conformance before selection into a Benchmark Dataset.
- Static case materials and executable Worlds remain separate. A document supplied to a Harness does not become a world merely because it affects execution.
## Case identity and change
Treat the persisted case identity as opaque. Do not construct IDs in client code or documentation. When case content changes materially, benchmark interpretation must use a snapshot or version boundary that makes the selected content clear.
Responses produced by a Harness are evaluation outputs attached to a Run. They are not the primary case input. Expert-authored acceptable examples can inform standards or contribution work, but the current evaluation contract should remain explicit about which candidate produced each response.
{% example-demo title="Example: multimaterial case" %}
A chat case asks whether an exception applies. Its required `current_policy` PDF and optional `account_history` table are stored as case materials admitted by Project Input Schema. The rendered case view presents the conversation and both materials. A benchmark snapshot selects the case, and a Run records the evaluated Harness response separately.
{% /example-demo %}
## Choose your next task
| Guide | What you can accomplish |
| --- | --- |
| [Represent conversations in Cases](/docs/object-model/represent-conversations-in-cases) | Preserve multi-message context in a Case’s canonical input. |
| [Import and prepare existing Cases](/docs/operating-manual/import-and-prepare-cases) | Bring cases into the project, conform them to Project Input Schema, inspect materials, and prepare benchmark selection. |
| [Synthesize Cases with Lemon Weave](/docs/coverage-engineering/synthesize-cases) | Generate benchmark-scoped input candidates from explicit coverage needs and the project input/material contract. |
| [Construct controlled variations](/docs/assets/controlled-variations) | Vary the condition under investigation while preserving enough shared context to interpret the difference. |
| [Review and admit Case candidates](/docs/coverage-design/case-review) | Inspect generated inputs and materials against their captured coverage purpose before relying on benchmark membership. |
| [Maintain reusable Cases across benchmarks](/docs/assets/reuse-cases) | Reuse project Cases while keeping benchmark membership and frozen assessment populations distinct. |
| [Lemon Weave](/docs/concepts/weave) | Construct Cases, controlled alternatives, supporting materials, and targeted training examples from coverage needs and expert judgment. |
| [Case Foundry](/docs/coverage-design/case-foundry) | Prepare Case candidates for Coverage Design from current requirements and captured project input settings. |
| [Boundary Cases](/docs/coverage-engineering/boundary-cases) | Use edge and ambiguous cases to sharpen policies, applicability logic, and rubrics. |
| [Candidate and In-Use Cases](/docs/coverage-engineering/candidate-and-in-use-cases) | Distinguish examples under consideration from cases that actively support benchmark results. |
| [Case Pool](/docs/coverage-engineering/case-pool) | Inspect reusable project Cases, preserve their input and provenance, and select them explicitly for a Benchmark. |
| [Case Segmentation](/docs/coverage-engineering/case-segmentation) | Segment cases into meaningful behavior groups so benchmark coverage is explainable. |
| [Case Versioning](/docs/governance/case-versioning) | Track meaningful changes to cases, metadata, context, and attached outputs. |
| [Case Pool surface](/docs/object-model/case-pool) | Understand Case Pool as the Assets view for reusable project Cases, candidates, and explicit Benchmark selection. |
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Project Input Schema](/docs/project-settings/input-schema)
- [Benchmark Datasets](/docs/benchmark-datasets)
- [Coverage Design](/docs/coverage-design)
{% /related-card-grid %}
---
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-11-06
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 source context is unavailable.
- Create a new Case version when the reviewable content changes; do not silently rewrite content captured 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 preserve earlier Case content when recording a meaningful change.
{% 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 %}
## Related task pages
{% related-card-grid title="Related workflows" %}
- [Assets](/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 %}
---
id: troubleshooting.unrealistic-synthetic-cases
title: Synthetic Cases That Feel Unrealistic
summary: Improve generated candidates whose surface details or behavior assumptions do not represent plausible target-system use.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-11-06
canonical: /docs/troubleshooting/unrealistic-synthetic-cases
---
# Synthetic Cases That Feel Unrealistic
## Symptoms
- Generated language sounds artificial or describes a user who would not exist in the product.
- Required context appears conveniently in the prompt even though the real system would retrieve it elsewhere.
- The Case combines incompatible ontology values or violates product constraints.
- Reviewers can identify the intended coverage tuple but would never admit the Case to a Benchmark.
- Many generated candidates repeat the same template with superficial wording changes.
## Likely causes
- The synthesis request lacks representative source Cases or product constraints.
- A coverage tuple combines values that cannot coexist in the target system.
- A Scenario or tuple is too broad, stale, or inconsistent with the target system.
- Generated candidates are being treated as reviewed Benchmark Cases before admission.
## Diagnose the generation boundary
1. Open the intended Benchmark's **Coverage Design → Canvas** and identify the coverage slice used for Case preparation. Use **Assets → Cases** to import real examples or create a reusable Case manually.
2. Compare the generated Case with real in-use Cases from the same behavior region.
3. Separate a bad surface realization from a bad coverage target. Awkward wording may need editing; an impossible product state requires revised Scenario or tuple context.
4. Check whether the generator lacked constraints that operators hold only in private memory.
5. Inspect the synthesis lifecycle and candidate state. A completed generation is still candidate material, not a selected Benchmark Case.
## Fix
- Add representative source Cases or explicit product constraints to the synthesis context.
- Refine the Scenario or tuple when its construction guidance combines incompatible conditions. Keep response-alternative guidance in Comparison Directions.
- Generate from a specific missing coverage tuple rather than asking for generic diversity.
- Edit a promising candidate when its behavioral boundary is sound and only presentation is weak.
- Reject candidates whose premise is impossible or whose source context cannot be justified.
- Review duplicates before adding any generated Case to a Benchmark.
Validate revised candidates with an expert who knows the target workflow. Ask whether the situation could occur, whether the system would receive the shown context, and whether the requested judgment matters. Only then classify and curate the Case for possible benchmark use.
## Prevention
Ground synthesis in reviewed source Cases, explicit product constraints, and a named coverage gap. Review the Scenario and tuple, inspect duplicates, and require Case review before adding generated candidates to a Benchmark or Snapshot.
## Related task pages
{% related-card-grid title="Related workflows" %}
- [Synthesize Cases](/docs/coverage-engineering/synthesize-cases)
- [Scenarios](/docs/coverage-engineering/scenarios)
- [Boundary Cases](/docs/coverage-engineering/boundary-cases)
- [Case Pool](/docs/coverage-engineering/case-pool)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference" %}
- [Case Pool surface](/docs/object-model/case-pool)
- [Cases](/docs/object-model/cases)
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
{% /related-card-grid %}