---
id: governance.case-versioning
title: Case Versioning
summary: Track meaningful changes to cases, metadata, context, and attached outputs.
kind: reference
product_area: governance
status: stable
updated: 2026-08-23
canonical: /docs/governance/case-versioning
---

# 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.

## Related objects

Read [Cases](/docs/assets/cases) for canonical Case structure, [Project Input Schema](/docs/project-settings/input-schema) for input and material requirements, and [Dataset Snapshots](/docs/benchmark-datasets/snapshots) for the immutable benchmark boundary. Use Benchmark Versioning when corrected Cases need to enter future evaluation evidence.

{% example-demo title="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.
{% /example-demo %}

## 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.

## Related task pages

{% related-card-grid title="Related task pages" %}
- [Cases](/docs/assets/cases)
- [Dataset Snapshots](/docs/benchmark-datasets/snapshots)
- [Benchmark Versioning](/docs/governance/benchmark-versioning)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}