What is OMMX?

OMMX (Open Mathematical prograMming eXchange) lets you describe what you want to solve separately from how you solve it. You can revise the formulation you send to a solver and still judge its candidates by the constraints and objective of the original problem. Connecting results back to those conditions helps you understand what to revisit in your requirements or input data. It is a system that grows through new declarations, analyses, and transformations while retaining shared meanings and responsibilities.

Responsibilities of modelers, OMMX, and adapters

A modeling tool expresses your requirements. OMMX provides a common data format and Python and Rust SDKs to transform the problem and evaluate candidates. An adapter is responsible for connecting that representation to a solver or sampler while preserving its meaning, and for interpreting candidates and termination reports against the problem actually solved. Implementing transformations on this common representation makes them reusable across modeling tools and solving methods.

This division of responsibilities is an OMMX contract. Adapters must meet this contract regardless of the coverage of individual implementations. Available features and support vary by operation and adapter; consult the API Reference for details.

Why use OMMX?

A common problem representation lets you divide the work as follows.

Your goal	Processing owned by OMMX	What you decide
Try a different formulation or solver	Supported special-constraint conversions and integer encodings; exchange with backends through adapters	The method, permitted transformations, and solver settings
Check whether a candidate is usable	Evaluate variable domains, constraints, and the objective; reconstruct original variable values from information retained by supported transformations	How to model the requirements of your application and whether to accept the candidate
Revisit requirements or input data using results	Identify objects by labels and retain the provenance of ordinary constraints generated from special constraints	How the modeler or application maps objects to source declarations and data, and what to revise
Pass problems and results to another process	Read and write a common format; save and share Artifacts; record settings and results in Experiments	What to record and what to compare

The problem can come from a modeling tool, a saved file, or the SDK. If the same model structure serves several sets of input values, a ParametricInstance lets you supply the parameters for each case.

You choose the requirements the model must satisfy, including when an AI tool helps write the model. You can use the SDK just to check a candidate from your own algorithm.

Evaluate a candidate you already have

A production line can make up to 100 units per hour, but only 60 in reduced mode. A plan that calls for 65 units in an hour of reduced operation violates that limit, whether the plan came from a solver or from a colleague. OMMX can evaluate either plan against the same problem. Evaluate candidates and interpret results explains how to distinguish checking this rule, checking the whole model, and establishing optimality. It also explains conclusions when no candidate is returned and how to connect results to the original conditions and data for revision. The Solution Reference shows how to evaluate a candidate and inspect the result.

Separate a problem’s meaning from its representation for solving

You can express the reduced-mode limit as an indicator constraint, which applies a condition when a binary variable takes a specified value. The PySCIPOpt Adapter can pass this linear indicator directly to SCIP. You can also use the known upper bound on output to express the same rule as an ordinary inequality and try that formulation with SCIP. In either case, the planner specifies the production rule once. Transform a problem and connect it to a solving method derives the inequality and explains which guarantees to check for other transformations.

OMMX is designed as an extensible system: new declarations and operations are added on top of shared meanings and responsibilities. The same principle of retaining structure before choosing a solver formulation applies to special constraints, evaluations such as assignment costs or route lengths, and objectives composed of several evaluation axes. For example, when treating cost, delay, and shortage counts as objectives, keep the individual axes separate from the choice of a weighted sum or lexicographic ordering. A customer’s stated priorities remain requirements that this choice must satisfy.

In this division of work, users, AI tools, and modelers clarify natural-language intent; common OMMX processing expands the agreed declarations into mathematical formulations. Adding declarations available to modelers such as JijModeling together with transformations that realize them reduces the need to construct that expansion separately for each application.

Accumulate analysis and transformation techniques on a common representation

Implementing preprocessing and transformations against a common representation lets modeling tools and solving methods reuse them. A new method can connect its inputs and outputs to that representation and benefit from the techniques already available. This is why OMMX develops both data exchange and shared processing of that data.

Separating analyses that inspect properties from transformations that rewrite a problem, and making their applicability conditions, information dependencies, and preservation guarantees explicit, provides the foundation for extending this system. New operations follow the same contracts so they can be combined with existing ones. Users choose the guarantees they need; delegating combinations that respect those guarantees to shared processing is the design for reducing manual work in checking each combination. See the relationship between analyses, transformations, and guarantees for details.

Support for specific declarations and operations grows continuously within this system. Consult API Reference for the features available and their conditions.

Start with your purpose

This introduction explains why you might adopt OMMX. The other three Book chapters can each be read on their own.

What do you need to decide?	Book chapter
Can the solver use my model directly? If I change its formulation, which properties must I preserve?	Transform a problem and connect it to a solving method
What can I conclude from a candidate, its absence, or a solver report? How do results connect back to requirements and data?	Evaluate candidates and interpret results
What should I keep so someone else can inspect a result or repeat a trial?	Save and share problems, results, and trials

To run something yourself, install the SDK and any adapter you need. Choose an example when you want to follow a whole task, such as sampling and plotting routes for a traveling salesperson.

For individual operations and their supported scope, start in the Python API Reference. Until the 3.0.0 stable release, the API Reference describes main. The installation guide covers both the latest published prerelease and installation from main. For example, Solution shows how to inspect a candidate and load_solution() reads one from a file. The adapter catalogue lists solver inputs and links to complete solve examples. To connect your own backend, see SolverAdapter or SamplerAdapter.

To inspect a solver’s search progress and termination report, see the SCIP or HiGHS diagnostic reference.

To work with saved data, inspect a local Artifact or share it through a registry. To connect an external tool, install an agent plugin or see ommx.tracing to send spans to an OpenTelemetry collector.

Support data exchange and sharing

Giving problems and results common meanings helps both software and people work with the same data. OMMX supports these handoffs through the following components:

Component	Role
OMMX Message	A language- and OS-independent data format for problems and results
OMMX SDK	Construction, evaluation, transformation, reading, and writing of problems and results
OMMX Adapter	Connection between OMMX and a solver’s inputs and outputs, and interpretation of reports about the problem solved
OMMX Artifact	A package for saving and sharing problems, results, and attachments with metadata

Message schemas are defined with Protocol Buffers, with SDKs provided for Python and Rust. In Python user code, use the public API, such as from ommx import Instance. The schema sources define the wire formats; a generated v1 Message Schema is also available.

Connect software through a common representation of problems and results.

Alongside problems and results, Artifacts can record what was solved and with which settings. They use OCI standards, so they can also be distributed through existing registries such as GitHub Container Registry. OMMX uses this mechanism to publish MIPLIB and QPLIB problems. The Artifact format specification defines manifests, layers, and media types for tools that need to read or write the format directly.