DecisionOps: A Step-by-Step Playbook for Running Optimization Models in Production

Machine learning teams spent the last decade learning MLOps: how to version models, test them, deploy them and watch them drift. Optimization teams are now facing the same journey. A scheduling or allocation model that works beautifully in a notebook can fail in production for reasons that have nothing to do with mathematics: a missing data feed, an infeasible constraint introduced by a business rule change, a solver upgrade that shifts results, or planners who quietly stop trusting the output.

This playbook describes DecisionOps, a set of engineering and operating practices for running optimization models as dependable production services. It is written for analytics leaders, operations research practitioners and platform engineers who want prescriptive models to deliver value every day, not only in the pilot readout.

Why Optimization Needs Its Own Operating Discipline

Optimization is moving from occasional studies to embedded, automated decision-making. Gurobi’s 2026 State of Mathematical Optimization Report, based on a survey of 382 non-academic professionals and released in October 2026, found that 52% of respondents say optimization supports ongoing decision-making in their organization and 45% run it automatically in production workflows. The same release reported that the share solving multi-objective problems rose from 32% to 40% year over year, and that 79% now use generative AI or LLMs in their optimization work.

Those trends raise the operational stakes. Models are larger and more complex, they run without a human expert watching each solve, and more of the code is drafted with AI assistance. Several characteristics make optimization different from predictive machine learning:

• Failure is binary as well as gradual. A model can become infeasible and return no answer at all, which a forecast model rarely does.
• Outputs are actions, not scores. A schedule or allocation goes straight into operations, so errors have immediate physical consequences.
• Logic lives in constraints. Business rules are encoded as constraints that change frequently and are easy to break.
• Solvers are non-deterministic in practice. Different versions, parameters, thread counts or hardware can yield different, equally optimal solutions, which confuses users if not managed.
• Trust is fragile. Planners override plans they do not understand. Without explanation and feedback loops, adoption decays.

The DecisionOps Lifecycle at a Glance

A production optimization service moves through six stages, each with its own controls:

1. Frame: define the decision, its owner, the objective, hard and soft constraints, and the KPIs used to judge plans.
2. Model: build and version the formulation in a solver-agnostic modeling layer.
3. Validate: test against curated instances, edge cases and business acceptance criteria.
4. Deploy: package the model as a service with clear inputs, outputs and service levels.
5. Operate: monitor data quality, solver behavior, plan quality and user overrides.
6. Improve: feed overrides and outcomes back into the model and constraint catalog.

The following sections walk through each stage with concrete practices.

Step 1: Frame the Decision and Write It Down

Many optimization failures start with an unclear decision. Before writing code, produce a short decision specification that business and technical stakeholders sign off on. It should cover:

• The decision being made, its frequency and its time horizon, for example daily crew assignments for the next 72 hours.
• The decision owner, who accepts or rejects plans and who arbitrates trade-offs.
• The objective, including weights or priorities for multiple objectives such as cost, service level and emissions.
• Hard constraints that must never be violated and soft constraints that can be relaxed at a penalty.
• KPIs used to evaluate plans, which may differ from the mathematical objective.
• Fallback behavior when no feasible plan is found.

Keep this specification in version control next to the model. When a planner asks why the model did something, the answer should trace back to a documented rule.

Step 2: Build a Maintainable Model

Separate data, logic and engine

Use a modeling library that supports multiple solver back ends so that the formulation does not depend on one engine. Keep input data loading, constraint generation and solver calls in separate modules. This separation makes it possible to swap solvers, test constraints in isolation and reuse data pipelines across models. It also matters as solver options multiply: open-source engines such as HiGHS now ship inside SciPy and other mainstream tools, and GPU-accelerated engines such as NVIDIA cuOpt can be called from common modeling layers.

Create a constraint catalog

Maintain a catalog that lists every constraint with a business name, description, owner, mathematical form and a flag for hard or soft. When the business introduces a new rule, it enters through the catalog with a change request rather than as an ad hoc code edit. The catalog doubles as documentation for auditors and new team members.

Use AI assistance carefully

Language models are now widely used to draft formulations, generate data loaders and explain solver logs. That speeds development, but generated code can introduce subtle errors such as wrong indices or missing constraints. Treat AI-drafted model code like any other contribution: peer review, unit tests and validation on known instances before merge.

Step 3: Validate Like You Mean It

Testing optimization models requires more than checking that the code runs. Build a layered test suite:

• Unit tests for constraints: small hand-built instances where the correct answer is known, verifying that each constraint behaves as described in the catalog.
• Regression instances: a curated set of 20 to 50 real historical inputs with stored reference solutions and KPI values. Any change must keep objective values and KPIs within tolerance.
• Infeasibility tests: deliberately broken inputs to confirm the service detects infeasibility, reports which constraints conflict and triggers the fallback.
• Performance tests: solve-time and memory limits on the largest realistic instances, including peak periods.
• Business acceptance: side-by-side review of model plans and planner plans for several cycles, with the decision owner signing off.

Automate the first four in a continuous integration pipeline so that every pull request, solver upgrade or parameter change triggers them.

Step 4: Deploy Optimization as a Service

Wrap the model behind an API or job interface with explicit contracts. Some solvers already expose service interfaces; NVIDIA, for example, documents a REST server for cuOpt alongside its Python API. Whatever the engine, the service should define:

• Input data contracts: schemas, required fields, ranges and freshness rules, validated before any solve begins.
• Run configuration: solver, version, parameters, time limits and optimality gap targets, stored with each run.
• Outputs: the plan itself, KPI values, solver status, gap achieved, and a short list of binding constraints or key drivers.
• Service levels: maximum time to plan, availability windows and escalation paths when the service fails.

Decide how plans reach operations. Some organizations publish directly into execution systems such as ERP, WMS or MES; others require human approval in a planning workbench. A common pattern is to auto-publish when KPIs fall within agreed bands and route exceptions to a planner.

Make solver behavior reproducible

Pin solver versions, fix random seeds and thread counts where the engine allows it, and record all parameters. When a solver upgrade is needed, run it through the regression suite and compare not only objective values but also how much plans change. Large plan changes with identical objectives can still disrupt operations.

Plan for stability, not just optimality

Operations teams dislike plans that reshuffle everything each time the model reruns. Add stability terms that penalize changes to already-communicated decisions, freeze windows for the near term, and limits on how many assignments may move between runs. A slightly less optimal but stable plan is often far more valuable on the shop floor or in the depot than a theoretically better plan that forces dozens of last-minute changes.

Step 5: Operate and Monitor

Production monitoring for optimization covers four layers:

1. Data health: late or missing feeds, unusual volumes, values out of range, and master data changes that could break constraints.
2. Solver health: solve times, optimality gaps, infeasibility rate, time-limit hits and memory use, trended over time.
3. Plan quality: KPIs such as cost, utilization and service levels, compared with targets and with historical plans.
4. Human acceptance: the rate and pattern of planner overrides, with reasons captured in the workbench.

Override monitoring is the most neglected and most informative signal. A rising override rate in one region or product family often reveals a missing constraint, outdated data or a rule the business changed without telling the model team.

Treat every planner override as free feedback. A rising override rate is the earliest warning that the model and the business have drifted apart.

Step 6: Close the Loop

Hold a monthly decision review with the decision owner, planners and the model team. Review KPIs, overrides, infeasibility incidents and pending constraint changes. Prioritize improvements by business impact. Over time, track realized outcomes, such as actual costs and service levels, against what the plan predicted, so that the model’s assumptions are tested against reality.

Governance and Roles

DecisionOps works only if responsibilities are clear. A lightweight RACI might include:

• Decision owner (business): accountable for plan acceptance, objectives and constraint priorities.
• Model owner (operations research or data science): responsible for formulation, validation and improvement.
• Platform owner (engineering): responsible for the service, pipelines, solver infrastructure and monitoring.
• Planners (users): review exceptions, provide override reasons and participate in acceptance testing.
• Risk and compliance: consulted where decisions affect people, safety or regulated activities, for example workforce scheduling.

Where optimization decides things about people, such as shift allocation, include fairness constraints and documentation in the decision specification, and make sure affected staff have a route to query outcomes.

Common Pitfalls

• Treating the pilot model as production code. Pilot notebooks often hard-code data paths, skip validation and mix logic with data loading. Budget time to refactor before scaling.
• Hiding infeasibility. Silently relaxing constraints to always return a plan can produce unsafe or non-compliant outputs. Make relaxations explicit and visible to planners.
• Optimizing the wrong objective. A model that minimizes cost while the business is measured on service level will be overridden constantly. Align the objective with the KPIs that leaders actually review.
• Upgrading solvers without regression testing. New versions are usually better on average, but individual instances can behave differently.
• No explanation layer. Planners need to see which constraints drove a decision. Even a simple list of binding constraints and their business names improves trust.

Hypothetical Example: Hospital Nurse Scheduling

Imagine a hypothetical hospital group that built a nurse rostering model in a six-week pilot. It worked well in one ward, but when rolled out to twelve wards it started returning infeasible results whenever a ward manager introduced local rules about weekend rotations.

Applying DecisionOps, the team writes a decision specification with the nursing director as decision owner, creates a constraint catalog that separates group-wide labor rules from ward preferences, and converts ward preferences into soft constraints with penalties. It builds a regression set of 40 historical rosters, adds infeasibility tests that report conflicting rules in plain language, and deploys the model as a service that publishes draft rosters to ward managers for approval. Override reasons are captured in a dropdown. After two months, override analysis shows most changes relate to staff training days that were missing from the input data. Fixing that feed improves acceptance more than any model change. This is a typical DecisionOps outcome: the biggest gains come from data and process, not exotic mathematics.

DecisionOps Readiness Checklist

• Is there a signed decision specification with an accountable owner?
• Are constraints documented in a catalog with owners and hard or soft flags?
• Does a regression suite run automatically on every change and solver upgrade?
• Are inputs validated against data contracts before solving?
• Is there a documented fallback when no feasible plan exists?
• Are solver versions, parameters and results logged for every run?
• Are override rates and reasons monitored and reviewed monthly?
• Can planners see why the model made a key decision?

Conclusion

Optimization delivers its value when it runs reliably every day, not when it wins a pilot. As more organizations automate decisions and use AI to build models faster, the discipline around those models matters more. DecisionOps borrows the best of MLOps and adds what optimization uniquely needs: constraint governance, infeasibility handling, reproducible and stable solver behavior, and override feedback. Start with the decision specification and the regression suite, give planners visibility into why the model decides as it does, and treat every override as data. The rest follows naturally, and the model earns the trust it needs to run at scale.

How Hanoi Technology Can Help

Hanoi Technology helps teams productionize optimization models with testing, deployment and monitoring practices, delivered as projects, dedicated teams or managed services.

• AI Planning & Optimization
• Managed Services
• Data Management
• Contact Us

Further Reading

• Gurobi’s 2026 State of Mathematical Optimization Report – Business Wire
• Accelerate Decision Optimization Using Open Source NVIDIA cuOpt – NVIDIA Developer
• HiGHS optimization solver – Wikipedia