Typed numerical plans, generated solvers, evidence and observability.
Core-2 Typed Solver Plans
Status: normative preview; bounded native typed plan construction/admission implemented; solver execution and generated-code admission unavailable
C2-SOLVER-001 — Plan contract. SolverPlan<Model> is an immutable typed
artifact proposing how to solve one named analysis of a physical model. It
contains model/analysis and dependency identities; unknowns and observation
space; original/derived meshes and projections; field discretization and basis;
assembled or matrix-free operator definitions; boundary/gauge treatment;
method/preconditioner and stopping policy; precision/rounding model; partition,
device and resource choices; tolerances; event/coupling law; and evidence
requirements. Every backend default affecting observations, termination,
resources or repeatability is resolved into the plan before execution.
C2-SOLVER-002 — Generation and authority. A backend, compiler or Optimize may propose a plan, including a generated ZergLang solver. The generator records its source, tool identity, input closure and generated body identity. Generated code goes through ordinary checked-language, effect and capability admission; a plan cannot smuggle an unchecked native library or arbitrary subprocess. Recursive solver generation has an explicit finite depth and total budget shared across nested proposals. Backend discretion concerns numerical method choice; it cannot modify the model or weaken acceptance tolerances.
C2-SOLVER-003 — Execution boundary. Solver.evaluate accepts a checked
plan reference, model parameters/conditions, a live Solver capability and a
bounded run request. The result records status, observations with units and
uncertainty, actual steps/resources, residual/error/conservation histories,
generated mesh/projection references, environment/tool identities and evidence.
The operation may use an admitted subprocess implementing
zerglang.solver-adapter/1, with the framing, request/response fields and
content-reference rules of target adapters. Its operations are
describe, validate_plan, evaluate; inputs are model, analysis, plan,
parameters, dependencies and toolchain references plus limits. The response
statuses and diagnostic/report rules are identical to target adapters.
validate_plan checks static compatibility, required feature support and
resource policy without claiming convergence. evaluate returns a result and
evidence artifacts; successful process exit does not establish a successful
solve. Cancellation, divergence, singular systems, unsupported operators,
exhausted resources and failed coupling are distinguishable outcomes. No
partial result is promoted unless the original contract explicitly accepts its
bounds and termination state. Flow records the complete result reference and
never reruns an already recorded decision during replay.
C2-SOLVER-004 — Numerical acceptance. Admission matches discretization spaces, dimensions, boundary conditions, target precision and model assumptions. Promotion checks observation errors, applicable residual/conservation/stability criteria, and convergence across admitted mesh/time-step refinements. Independent evidence must not merely reuse the same generated solver and report under another wrapper. Analytical solutions, manufactured solutions, independent discretizations/solvers and calibrated experiments identify what they validate: numerical implementation, model consistency, or physical fidelity. A solver run proving numerical convergence is not automatically a validated physical realization. Comparisons use contract norms and error envelopes; solver outputs need not be bit-identical unless the contract requires that property.
C2-SOLVER-005 — Lifecycle and observability. Plans progress through proposed, checked, evaluating, admitted/rejected and promoted/quarantined states with immutable evidence references. Execution has bounded progress, resource, residual and uncertainty data. The future runtime must project this state through the canonical Zerg snapshot and ZDE, including model/plan ownership, selected realization, validity envelope and instability. No UI-only state store may replace that contract. Snapshot and visible behavior tests are required in the paired implementation work; this specification creates no runtime state today.