Inputs
- Decision constraints and hard bound pairs
- Policy context and candidate request from the Control Plane
- Invariant set from the translated contract
Control and decision
IDM Solver
Feasible decisions inside hard constraints.
Invariant-Dynamic Machine decision model and its supported solver capabilities for constrained decisions.
Responsibility
What IDM Solver is responsible for
The IDM Solver produces decision candidates that satisfy specified hard constraints and reports when no feasible candidate exists. It is a decision aid inside the Control Plane, not an authority: feasibility does not imply authorisation.
Some governance decisions are constrained selection problems: choose an allocation that satisfies hard bounds while respecting declared invariants. The IDM (Invariant-Dynamic Machine) model provides the decision structure; the implemented solver produces feasible candidates for a bounded allocation shape.
The honest boundary matters here. The reviewed solver is an α-fair single-resource allocator with a prototype multi-resource projection and a hard-bounds guard, not the full optimiser described in early architecture material. A feasible candidate is an input to a governed decision, not a permission.
Lifecycle position
Where it sits in the governance lifecycle
Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.
Decision
Coordinate policy, constraints and uncertainty.
Verified capabilities
What is verified today
Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.
- α-fair single-resource allocation within declared bounds
- Opt-in multi-resource projection (prototype)
- Default hard-bounds guard that blocks out-of-bound candidates
- Explicit infeasibility reporting instead of a forced answer
- Integration hooks for the Control Plane candidate pipeline
Outputs
- Feasible decision candidate
- Infeasibility result with the violated constraint
- Candidate records for approval and audit
Evidence and maturity
What the evidence supports
Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.
Maturity note
A standalone solver endpoint implements an α-fair single-resource allocation with an opt-in multi-resource projection and a default hard-bounds guard. It is not on the intent path, and the specified IDM-FULL/v1 optimisation mode is not selectable in production.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- Standalone solver endpoint and Control Plane candidate-solver tests.
- IDM review branch record (approval-crypto) in the engineering ledger.
- Known-limitations register entries 5–7; NTC/IDM solver design note.
Dependencies
- Control Plane
- λ-Safe contract constraints
Dependencies are stated as the product register records them. A dependency is not automatically production-qualified; see its own product or component page for its maturity and limitations.
Limitations
What this product does not do (yet).
Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.
Limitations — read before evaluating
- Not the specified optimiser: IDM-FULL/v1 is not selectable in production in the reviewed configuration.
- The solver operates standalone and is not integrated into the intent path.
- The 2×2 grid candidate has no optimality-gap proof; CLF/CBF constraints are synthetic; chance, CVaR and oscillation handling are post-solve steps.
- A feasible decision candidate is not an authorisation and cannot be dispatched without a permit.
No capability on this page should be read as production qualification. If a limitation is material to your use case, it belongs in the evaluation scope — not after it.
Relationship to the platform
How it fits
IDM improves the quality of a decision candidate. Gatekeeper still decides admission, λ-Safe still defines the supported invariants, and the Control Plane still owns the transaction record.
Evaluation questions
- Which decision shapes are supported today?
- What is reported when the constraint set is infeasible?
- Which optimality or risk claims are backed by proof rather than post-solve heuristics?
Next step
Evaluate IDM Solver against a real control problem.
Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.