Module core 

Framework: traits, state shapes, the iteration driver, and the termination layer. The slot taxonomy is:

• problem: what the user implements about their objective: CostFunction, Gradient, MiniBatchGradient (finite-sum, for mini-batch SGD), Residual/Jacobian (least squares), and Hessian (second order). Future: operators (matrix-free).
• numdiff: finite-difference derivative synthesis: the FiniteDiff wrapper adds Gradient/Jacobian/ Hessian to a problem that only exposes function values.
• constraint: constraint markers carried on the problem (tenet 4 in CONTRIBUTING.md): BoxConstraints, LinearInequalityConstraints, LinearEqualityConstraints, and the general-form LinearConstraints aggregator consumed by LINCOA.
• barrier: the LogBarrier adapter that rewrites a linearly-constrained problem as the unconstrained log-barrier objective consumed by the BarrierMethod.
• state: what a solver carries between iterations: State for the minimum, GradientState/ SimplexState when a solver carries richer info that termination criteria can read.
• solver: the Solver trait every concrete solver implements. Lifecycle is init once, then repeated next_iter, with an optional terminate hook.
• termination: the framework-level TerminationCriterion trait plus shipped criteria. Each criterion bounds on the minimum state shape it needs (tenet 3), so mismatches are compile errors rather than runtime no-ops.
• observer: read-only side-effect hooks fired around the loop (Observe + ObserverMode). Sibling to termination: observers watch, criteria decide.
• executor: the driver: Executor/ Stepper/run_loop. The canonical iteration ordering is documented on the executor module.
• inner: the composition adapter: InnerExecutor wraps run_loop for outer solvers that drive an inner solver per outer iteration. See CONTRIBUTING.md “Solver composition” for the contracts.
• math: the small shared math layer (ScaledAdd, NormSquared, …) that backend-generic solvers depend on. Per tenet 5, this stays honest: only ops every backend can implement well live here. LA-heavy ops will live in a separate tier when the first solver wants them.

Modules

augmented_lagrangian

Augmented-Lagrangian adapter for linear equality constraints.

barrier

Log-barrier adapter for linear inequality constraints.

constraint

Constraint markers carried on the problem (tenet 4 in CONTRIBUTING.md). BoxConstraints (interval bounds, consumed by projection-based solvers), LinearInequalityConstraints (A x ≤ b, consumed by the log-barrier method), LinearEqualityConstraints (A x = b, consumed by the augmented-Lagrangian method), and NonlinearInequalityConstraints (c(x) ≤ 0 for an arbitrary vector-valued c, consumed by COBYLA).

executor

Iteration driver. The high-level entry point is Executor; Stepper exposes one-iteration-at-a-time control, and run_loop is the borrowed-problem variant used by composed solvers.

inner

Composition adapter: drive an inner solver from inside an outer solver’s next_iter.

math

Math abstraction the solvers depend on.

numdiff

Finite-difference derivative synthesis.

observer

Read-only side effects fired around the iteration loop.

problem

Problem traits the user implements about their objective. Solvers bind on whichever subset they need (e.g. gradient descent requires CostFunction and Gradient; Nelder-Mead only needs CostFunction).

rng

Seedable, wasm-safe RNG used by stochastic solvers.

solver

The Solver trait every concrete solver implements. See the trait contract for the lifecycle (init once, then repeated next_iter, with an optional terminate hook) and the executor module for the canonical iteration ordering.

state

Solver state shapes.

termination

Termination layer: the TerminationCriterion trait and the framework-level criteria solvers can be terminated by. Each criterion bounds on the minimum state shape it needs (tenet 3 in CONTRIBUTING.md), so mismatches are compile errors rather than runtime no-ops.