---
id: coverage-management.case-foundry
title: Case Foundry
summary: Generate or update bounded case candidates from the saved coverage setup and Story map.
kind: task
product_area: coverage_management
status: stable
updated: 2026-08-22
canonical: /docs/coverage-management/case-foundry
---

# Case Foundry

## Prerequisites

- Ready coverage setup, active Stories, and actionable tuple targets.
- A current input snapshot whose freshness can be verified.

Case Foundry coordinates bounded case preparation from the saved coverage setup and Coverage Stories. Use **Generate** for the first run and **Update** after the governed inputs change. A blocked action means required setup, readiness, or upstream evidence is not yet available.

## Run states and freshness

A Foundry run reports `QUEUED`, `RUNNING`, `COMPLETED`, `PARTIAL`, `FAILED`, or `CANCELLED`. Keep the run identity and input snapshot together when diagnosing it. Completion can report Cases added, synthesized, or retrieved; these counts explain construction activity, not acceptance into trusted benchmark evidence.

The workspace distinguishes a fresh result from one whose input snapshot changed. If coverage setup, Story structure, or relevant dataset context changed after the run began, update the Foundry work. Do not use an old completion badge as proof that the current coverage contract has been handled.

## Before and after Foundry

Before running, make the setup ready, activate the intended Stories, and check tuple targets. If a specialist must settle an ambiguous standard, request an Expert Contribution instead of generating around the ambiguity.

After running, open Case Review. Prepared candidates start as reviewable material rather than automatically becoming durable benchmark Cases. Inspect their evidence fit, sources, facet traces, inputs, and generated artifacts. Remove weak or redundant candidates and resolve material failures before inclusion.

> Case Foundry is not a Dataset Snapshot
>
> Foundry prepares candidates. Case Review admits suitable Cases into the current benchmark set, and Benchmark Datasets creates the immutable Snapshot used for evaluation.

## Failure handling

For a partial or failed run, preserve successful bounded work, read the failure detail, and retry only the missing scope when the product offers that action. Cancellation stops the current operation; it does not roll back Cases already materialized by a completed portion. Recheck freshness after any retry.

## Object and state changes

A Foundry action creates a run and can prepare, synthesize, retrieve, or add candidate Cases. Update creates new bounded work from changed input. The run does not create a Dataset Snapshot or bypass Case Review.

## Success criteria

- Terminal status and input freshness are known.
- Summary counts are interpreted as construction activity.
- Prepared candidates move to review rather than automatic trust.

## Common failure modes

- Treating `COMPLETED` as Case acceptance.
- Retrying stale work without updating its input.
- Generating around an unresolved correctness question.

## Related reference pages

{% related-card-grid title="Related reference pages" %}
- [Coverage Management](/docs/coverage-management)
- [Coverage Stories](/docs/coverage-management/coverage-stories)
- [Benchmark Dataset Cases](/docs/benchmark-datasets/cases)
{% /related-card-grid %}

## Related troubleshooting pages

{% related-card-grid title="Related troubleshooting pages" %}
- [Unrealistic synthetic Cases](/docs/troubleshooting/unrealistic-synthetic-cases)
- [Unclear Cases](/docs/troubleshooting/unclear-cases)
{% /related-card-grid %}

## Source confidence

Code-backed: the active Foundry API, run types, and workspace hook define actions, states, freshness, and summary counts. Case acceptance is verified in the separate Case Review surface.