Teammately Docs
Docs menu

reference

Cases

Understand canonical project cases, their input and materials, and how they become members of benchmark datasets.

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.

Worked example

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.

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

Reference / Project SettingsProject Input SchemaDefine the canonical input architecture, case-material fields, and accepted artifact formats for project cases.Concept / Benchmark DatasetsBenchmark DatasetsSelect benchmark Cases, inspect representation, and freeze immutable Snapshots for reproducible evidence.Concept / Coverage ManagementCoverage ManagementManage benchmark coverage from setup through representation, Coverage Stories, case review, Case Foundry, and contribution requests.

Found something unclear?

Report outdated, unsupported, or confusing docs so we can fix the source page.

Report a docs issue

Continue learning

Related docs

Assets Assets Manage reusable project cases, worlds, project tools, harnesses, weights, comparison directions, and review screens before selecting them for benchmark work. Project Settings Project Input Schema Define the canonical input architecture, case-material fields, and accepted artifact formats for project cases. Benchmark Datasets Benchmark Datasets Select benchmark Cases, inspect representation, and freeze immutable Snapshots for reproducible evidence.
AI context