Source of truth
CaseSpec is the semantic contract. Solver files are the executable reality. Chat text is useful context, but boundary conditions, material constants, QoIs, and validation targets are recovered from the typed state — not from prose.
What a CaseSpec owns
A CaseSpec owns:
- Solver identity and version
- Physics regimes (incompressible, compressible, thermal, structural, multiphase)
- Geometry references and named selections
- Mesh intent (target resolution, boundary-layer treatment, quality gates)
- Materials and constitutive models
- Boundary and initial conditions
- Solver controls (schemes, relaxation, tolerances, timestepping)
- Post-processing recipes
- Validation plan (
ValidationSpec) - Optional study coordinates (
StudySpec) - File manifest, run history, and report inputs
Input Package: the frozen derivative
The Input Package (ADR 0011) is a versioned, content-addressed snapshot derived from a CaseSpec at the moment of a run. It is not a second editable CaseSpec — you edit the spec, then re-materialize. This keeps runs reproducible while leaving the spec free to evolve.
Patch typed state, then materialize files
Direct UI edits and agent changes converge on typed patch operations. Solver adapters then materialize dictionaries, config files, input decks, mesh handoffs, summaries, and command candidates from that state. There is no parallel hand-edited shadow file.
Staleness is explicit
Changing upstream state stales downstream files, runs, figures, and reports. The platform records these cascades — you never have to guess whether a mesh, solver setup, or report is current.