T2-4: Continuous-time formalization

[rororowyourboat]

Problem

gds-continuous currently bypasses GDSSpec entirely — it builds ODEModel directly with no connection to the canonical form. The specification/simulation separation needs to be made explicit.

Type

[MATH] [DOC] [CODE]

Prioritization

• Criteria: C2 (Completeness)
• Tier: 2 — Medium Priority
• Phase: 4 — Analysis & Behavioral
• Dependencies: T1-1, T1-3

Current State

• gds-continuous is standalone (pydantic-only, no gds-framework dependency)
• Provides ODEModel, ODESimulation, ODEResults
• No spec_to_ode_model() adapter (unlike gds-analysis's spec_to_model())
• gds-symbolic creates ODE functions from control models but doesn't route through GDSSpec

Architectural Principle — Specification ≠ Simulation

A continuous-time specification is valid independent of any solver:

dx/dt = f(x(t), g(x(t), u(t)))
y(t)  = C(x(t), g(x(t), u(t)))

The specification belongs in gds-framework (as a continuous-time ExecutionContract). The solver belongs in gds-continuous.

Steps

1. Define continuous-time specification. When a GDSSpec is a valid continuous-time system: Mechanism blocks produce vector field terms dx/dt = ...; state subspace declared real-valued. Specification only — no solver commitment.

2. Add time_domain="continuous" ExecutionContract entry. Scoped to declared numerical subspace. No solver metadata.

3. Define SolverInterface protocol in gds-continuous:

   class SolverInterface(Protocol):
       def step(self, f: Callable, x: ndarray, d: Any, dt: float) -> ndarray: ...

4. Refactor gds-continuous. Read ExecutionContract from compiled SystemIR. Dispatch to SolverInterface-compliant implementation. Provide RK4 and scipy as reference implementations.

5. Build spec_to_ode_model() adapter. Bridges GDSSpec with continuous ExecutionContract to ODEModel. Parallel to gds_analysis/adapter.py.

6. Side-by-side thermostat example. Discrete-time vs. continuous-time GDSSpec. Same wiring topology and canonical decomposition; different ExecutionContract and solver.

Separation Table

Concern	Layer	Package
Continuous-time specification	Specification (ExecutionContract)	gds-framework
What a solver must satisfy	Interface contract (SolverInterface)	gds-continuous
Concrete numerical integration	Implementation (RK4, scipy)	gds-continuous
Discrete-event simulation	Event queue + zero-crossing	Future item

Deliverables

• Continuous-time specification definition
• ExecutionContract time_domain="continuous" entry
• SolverInterface protocol in gds-continuous
• RK4 and scipy reference implementations
• gds-continuous refactor to read ExecutionContract
• spec_to_ode_model() adapter
• Side-by-side thermostat example
• Tests

---

Part of the GDS-Core Improvement Roadmap

Scientific Context

Evidence level: Level 2 (Semantic) — extends the specification/simulation separation to continuous time. The claim: a continuous-time GDSSpec (dx/dt = f(x, g(x, u))) is a valid formal object independent of any solver. The solver is a simulation-layer concern.

This directly addresses ~40% of the paper's mathematical content (Sections 3-4: continuous-time dynamics, differential inclusions) which is currently unimplemented.

Verification Strategy

Cross-built equivalence. The thermostat as both discrete-time and continuous-time GDSSpec:

• Wiring topology and canonical decomposition must be identical
• ExecutionContract differs (discrete vs continuous)
• Solver differs (discrete stepper vs RK4/scipy)
• Behavioral trajectory should converge to the same steady-state (within solver tolerance)

Solver interface compliance. For each reference implementation (RK4, scipy):

• First-order consistency: lim_{Δt→0} x̃/Δt = f(x, d)
• Known-solution tests: solve systems with closed-form solutions (exponential decay, harmonic oscillator), verify error bounds
• Solver interchangeability: same spec + different solvers → trajectories converge to same result as Δt → 0

Adapter correctness. spec_to_ode_model() must produce an ODEModel whose RHS is consistent with the GDSSpec's Mechanism blocks. Cross-validate against the existing spec_to_model() for the discrete case.

Showcase

The side-by-side thermostat example: same system, same canonical form, different time models, different solvers, convergent results. This is the concrete demonstration that specification and simulation are genuinely separate concerns.