Teammately Docs
Docs menu

reference

Case Versioning

Track meaningful changes to cases, metadata, context, and attached outputs.

Case Versioning

Definition

A Case has durable identity and versioned canonical content. The exact Case version records the input shape and Case Materials that an evaluator or Harness received. Customer provenance and classification context can help find and interpret the Case, but they must not obscure which canonical version a historical Benchmark Version froze.

Fields, states, or lifecycle rules

  • A change to canonical input or required Case Materials creates a new evidence meaning and must remain distinguishable from the earlier version.
  • Project Input Schema determines the accepted input kind and named Case Material slots.
  • Correcting a filename label or customer-owned filter may be operational metadata; do not claim that every metadata edit has the same consequence as changed evaluated content.
  • Accepted or golden output changes affect reference-output interpretation and should be traced separately from the Case input version.
  • Existing Snapshots and Runs continue to identify the Case version they used.
  • A current Case can be selected by several Benchmarks; version review must consider each future dataset that uses it.
  • Case IDs and version IDs are backend-issued opaque values.

Read Cases for canonical Case structure, Project Input Schema for input and material requirements, and Dataset Snapshots for the immutable benchmark boundary. Use Benchmark Versioning when corrected Cases need to enter future evaluation evidence.

Worked example

Correcting a controlling document

A Case asks whether an opened product is returnable, but its attached policy PDF is discovered to be superseded. Replacing that Case Material changes the evidence presented to the candidate and evaluator, so the corrected Case must remain distinguishable from the old version. Runs against the old Benchmark Version stay interpretable as historical evidence; the corrected Case enters a new Dataset Snapshot for future Runs.

Source confidence

Code-backed: canonical Case content and Project Input Schema services define input and material structure, while Case view types preserve backend-issued Case identity for product surfaces. Exact persistence mechanics remain internal; Snapshot pages define public historical evidence behavior.

Found something unclear?

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

Report a docs issue

Continue learning

Related docs

AI context