# Cases Generated: 2026-09-13T04:33:15.249Z Source build: local Canonical docs: https://teammately.ai/docs --- id: object-model.cases title: Cases summary: Understand cases as the situations Teammately uses to represent important AI behavior. kind: reference product_area: object_model status: stable updated: 2026-08-23 canonical: /docs/object-model/cases --- # Cases ## Definition Cases are the behavior situations Teammately uses for review, coverage, and benchmark evidence. A case should preserve the input, source context, metadata, and version boundary needed to understand what behavior is being judged. Use this reference when a workflow depends on whether an example is reviewable, benchmark-ready, stale, duplicated, or missing the context a reviewer needs. ## Fields, states, or lifecycle rules - A case is not the same thing as an output; the case holds the situation and context, while the output is the behavior being judged. - A case can be useful for coverage planning before it is ready for benchmark use. - Case versions matter when source context, metadata, or expected behavior changes. - A benchmark result is weak if the failed output cannot be traced back to the exact case version. - Exact import schema and export behavior belong to source-backed integration pages, not this object reference. ## Related objects Cases should be read with [Outputs](/docs/object-model/outputs), [Case versions](/docs/governance/case-versioning), [Case pool](/docs/object-model/case-pool), and [Benchmarks](/docs/object-model/benchmarks). Use [Importing cases](/docs/operating-manual/import-and-prepare-cases) when the next step is bringing source examples into Teammately. {% example-demo title="Cases boundary" %} Raw record: A transcript includes a customer question, assistant answer, account context, and later human correction. Case: The reviewable unit preserves the customer question and account context. Output: The candidate answer is attached separately so reviewers know which behavior is being judged. Interpretation: If the candidate fails later, the run result can point to the exact case and output rather than to a vague transcript. {% /example-demo %} ## Source confidence Code-backed: Case view types and the Cases asset route establish the product object and its presentation; internal Case-content types establish how input and contextual material remain separate from outputs. These implementation sources support object semantics, not a customer-facing serialization contract. ## Related task pages {% related-card-grid title="Related task pages" %} - [Case model overview](/docs/assets) - [Case Pool](/docs/coverage-engineering/case-pool) - [Case pool](/docs/object-model/case-pool) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} --- id: assets.cases title: Cases 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-08-22 canonical: /docs/assets/cases --- # Cases ## 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 evidence 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 they are trusted as benchmark evidence. - 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 %} ## Source confidence Code-backed: the active Assets Cases route and case-content services define canonical input, case materials, and the rendered case view. Public import or export APIs are outside this reference unless separately documented. ## Related task pages {% related-card-grid title="Related task pages" %} - [Configure Project Input Schema](/docs/project-settings/input-schema) - [Work with Benchmark Datasets](/docs/benchmark-datasets) - [Manage benchmark coverage](/docs/coverage-management) {% /related-card-grid %} --- id: coverage.case-pool title: Case Pool summary: Use the Case Pool to collect, triage, enrich, and promote candidate cases. kind: concept product_area: coverage_engineering status: stable updated: 2026-09-07 canonical: /docs/coverage-engineering/case-pool --- # Case Pool ## Definition Case Pool is the project-level working set for reusable Cases and Case sourcing activity. The current UI routes Case inspection through **Assets → Cases** and keeps **Sourcing Tasks** under Coverage Engineering. Together they let operators inspect Case content and provenance, follow preparation tasks, classify coverage, and select Cases for one or more Benchmarks. ## Why it matters Cases often arrive before the team knows whether they are clear, representative, or tied to a meaningful coverage need. The Case Pool provides a project boundary where imported, generated, or contributed Cases can be reviewed without treating every item as benchmark evidence. ## Where it appears in the product Use Assets → Cases for the reusable Case collection. Use Sourcing Tasks to inspect find, synthesize, classification, and preparation activity. From selected Cases, use the supported add-to-benchmark action to change editable Benchmark Dataset membership. Use Benchmark Datasets to inspect the selected set and create Snapshots. ## Artifacts it affects Each Case keeps backend-issued identity, canonical content, materials, source or contributor context, Coverage Facet assignments, and benchmark inclusion where available. Task state is not Case approval, and benchmark inclusion is not Snapshot membership. Preserve those separate states when reporting progress. ## Operational check Before selecting a Case, inspect its canonical input, required materials, source trace, coverage assignments, and any supported reference output or evaluator relationship relevant to the intended Benchmark. Check for near duplicates and verify that selection closes a named need rather than merely increasing row count. ![Add to benchmark dialog listing available Benchmarks, their status, Case count, and last-updated time.](/docs-assets/assets/screenshots/case-pool-add-to-benchmark-modal.png) Selection is explicit: choose the intended Benchmark in this dialog. The action changes editable dataset membership, not a historical Snapshot. {% example-demo title="Routing a sourced Case" %} A sourcing task finds a production-informed question involving a superseded policy attachment. The operator opens the Case in Assets, confirms the current Input Schema and both materials, assigns the source-authority Coverage Facet, and adds it to the support Benchmark's current dataset. The team reviews Representation and creates a new Snapshot later; the selection action alone does not change historical Runs. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Assets](/docs/assets) - [Importing cases](/docs/operating-manual/import-and-prepare-cases) - [Synthesize cases](/docs/coverage-engineering/synthesize-cases) - [Dimensions and ontology](/docs/coverage-engineering/dimensions-ontology) - [Product quickstart](/docs/quickstart) {% /related-card-grid %} ## Source confidence Code-backed: current Case Pool navigation separates reusable Assets Cases from Sourcing Tasks, while Case sourcing types expose provenance, coverage targets, classification context, and benchmark inclusion. Benchmark Dataset pages own selection and Snapshot evidence. --- id: object-model.case-pool title: Case Pool surface summary: Understand Case Pool as the Assets view for reusable project Cases, candidates, and explicit Benchmark selection. kind: reference product_area: object_model status: stable updated: 2026-09-07 canonical: /docs/object-model/case-pool --- # Case Pool surface ## Definition **Case Pool** is a tab under **Assets → Cases**, not a separate Case object type. It shows reusable project Cases and candidate material that can be inspected before explicit selection into a Benchmark Dataset. Use this reference when deciding whether a Case should stay in the project collection, be prepared further, or be selected for a Benchmark. **Sourcing Tasks** is the adjacent job and audit surface; it is not another Case state. ## Fields, states, or lifecycle rules - Case Pool can contain useful Cases that are not selected into any Benchmark. - Candidate and in-use labels describe curation and membership context; they do not create a different persisted Case type. - Coverage dimensions and ontology values help explain what behavior the pool represents. - Adding a Case to a current Benchmark Dataset changes mutable membership. A new Dataset Snapshot is required to freeze that change as an evidence boundary. - This page does not define public upload schemas, export contracts, or retention behavior. ## Related objects Read Case Pool with [Cases](/docs/object-model/cases), [Candidate and In-Use Cases](/docs/coverage-engineering/candidate-and-in-use-cases), [Coverage Dimensions](/docs/object-model/coverage-dimensions), and [Benchmark Dataset Cases](/docs/benchmark-datasets/cases). Use [Case Pool](/docs/coverage-engineering/case-pool) for operating instructions. {% example-demo title="Case pool boundary" %} Raw case: A new support transcript shows a refund exception question that reviewers have not seen before. Case pool state: The example is a candidate case because it may close an exception-handling coverage gap. Interpretation: It should not affect benchmark scores until source context, output identity, coverage labels, and benchmark membership are clear. {% /example-demo %} ## Source confidence Code-backed: the Assets Cases routes expose Case Pool and Sourcing Tasks tabs, candidate and in-use views, and an explicit add-to-Benchmark action. Case Pool is therefore a curation surface, not automatic Benchmark membership, a separate Case schema, or a public storage contract. ## Related task pages {% related-card-grid title="Related task pages" %} - [Case Pool](/docs/coverage-engineering/case-pool) - [Candidate and In-Use Cases](/docs/coverage-engineering/candidate-and-in-use-cases) - [Cases](/docs/object-model/cases) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %}