Operations Research Algorithm Developer

Operations Research Algorithm Developer

When to Use

• Frame a decision problem as an optimization model—objectives, decisions, constraints, parameters, uncertainty
• Build LP, MIP, QP, or constraint programming formulations for planning and allocation
• Model network flows, assignment, routing (VRP), scheduling, and resource allocation
• Design inventory and production planning models (lot sizing, capacity, multi-period)
• Select exact vs heuristic methods—branch-and-bound, column generation, decomposition, metaheuristics
• Run sensitivity analysis, infeasibility diagnosis, and benchmarking (optimality gap, runtime)
• Integrate solvers conceptually—OR-Tools, Gurobi, CPLEX, HiGHS, PuLP, Pyomo—and production patterns
• Prepare input data, validate units, and enforce constraint modeling discipline
• Productionize OR services—APIs, timeouts, warm starts, incremental solves, solution pools

When NOT to Use

• General ML predictive modeling, feature engineering, A/B tests, or MLOps → data-scientist
• Supply chain strategy, RFQ, supplier scorecards, or inventory policy without optimization math → supply-chain-manager
• WMS workflows—waves, pick paths, RF scanning, ERP/WMS integration → wms-developer
• Simulation platform software—physics engines, SIL/HIL rigs, deterministic replay frameworks → simulation-software-engineer
• Generic backend, CRUD APIs, or cloud microservices without OR models → senior-software-engineer
• Analytics warehouse, dbt marts, dimensional modeling, BI semantic layers → analytics-data-engineer
• Formal proof obligations or certified assurance cases → software-assurance-formal-methods-specialist

Related skills

Core Workflows

1. Scope and problem class

Clarify decision horizon, granularity, optimality requirements, and handoffs to product/engineering.

See `references/or_algorithm_developer_scope.md`.

2. Formulation and data

Define sets, parameters, variables, objective, constraints; validate data and units.

See `references/problem_formulation_and_data.md`.

3. Linear and integer optimization

LP/MIP/QP structure, big-M discipline, tightening, decomposition hooks.

See `references/linear_and_integer_optimization.md`.

4. Routing, scheduling, and networks

VRP variants, job-shop and resource scheduling, min-cost flow and assignment patterns.

See `references/routing_scheduling_and_networks.md`.

5. Heuristics and metaheuristics

When to leave exact solvers; construction, local search, GA/SA/TS; solution quality metrics.

See `references/heuristics_and_metaheuristics.md`.

6. Solver integration and production

Solver choice, model lifecycle, APIs, timeouts, warm starts, monitoring, and failure modes.

See `references/solver_integration_and_production.md`.

Outputs

• Problem formulation brief—decisions, objective, hard vs soft constraints, assumptions
• Mathematical model—notation, formulation, linearization notes, parameter catalog
• Data specification—required inputs, validation rules, unit checks, scenario keys
• Solution report—objective, gap, runtime, binding constraints, sensitivity highlights
• Infeasibility / IIS summary—conflicting constraint groups and remediation options
• Implementation outline—solver stack, API contract, timeout and fallback policy
• Benchmark table—instances, gap %, time, memory, method comparison

Principles

• Formulate before coding—write the math (even briefly) before choosing a solver API
• Separate data from model—parameters drive constraints; avoid hard-coding scenario logic in solver calls
• Prefer tight formulations—fewer binaries, tighter bounds, and valid inequalities over brute force
• Measure optimality—report gap, bounds, and time limits; never imply optimality without proof
• Diagnose infeasibility systematically—IIS, elastic filters, or constraint relaxation ladders
• Production OR needs SLOs—timeouts, warm starts, and feasible incumbent policies are part of the design
• Route non-OR work to peers—ML, WMS features, and sim platforms are not substitutes for correct OR scope

When to load references

Heuristics and metaheuristics

Table of contents

1. When to use heuristics 2. Construction heuristics 3. Local search 4. Large neighborhood search 5. Metaheuristics 6. Hybrid with exact methods 7. Quality measurement 8. OR-level simulation

When to use heuristics

Always retain benchmark instances where exact or strong bounds exist.

Construction heuristics

Document determinism (tie-breaking) for reproducible tests.

Local search

First improvement vs best improvement—trade runtime vs quality.

Large neighborhood search

1. Destroy part of solution (random, related, worst) 2. Repair with exact subroutine (MIP/CP) or greedy 3. Accept if better (or simulated annealing rule)

Strong for VRP and scheduling at scale when paired with OR-Tools or custom repair MIPs.

Metaheuristics

Avoid tuning folklore without validation on held-out instances.

Hybrid with exact methods

Report gap vs branch-and-bound bound when available.

Quality measurement

Publish Pareto runtime vs quality curves when choosing production defaults.

OR-level simulation

Use for:

• Queueing—M/M/c, G/G/1 approximations; staffing sensitivity
• Discrete-event lightweight models—verify plan under stochastic arrivals (not full sim platform)
• Monte Carlo over demand/cost scenarios when closed form unavailable

Do not conflate with `simulation-software-engineer` (runtime, sensors, replay engines).

Linear and integer optimization

Table of contents

1. Model families 2. LP workflow 3. MIP workflow 4. Formulation patterns 5. Big-M discipline 6. Valid inequalities and tightening 7. Decomposition (conceptual) 8. QP and conic notes

Model families

LP workflow

1. Build sparse constraint matrix or algebraic model 2. Check feasibility with Phase I or solver presolve 3. Solve; read duals only when sure model is pure LP (no degeneracy caveats documented) 4. Sensitivity: allow objective/rhs ranges where solver supports it 5. Report objective, dual summary (optional), binding constraints

MIP workflow

1. Start from LP relaxation—bound quality predicts difficulty 2. Set time limit and MIP gap upfront; align with business SLO 3. Enable presolve, cuts, and heuristics (solver defaults often good) 4. Track incumbent improvement curve for tuning 5. If gap stalls—tighten formulation before raising time limit indefinitely

Formulation patterns

Prefer SOS and indicator constraints when solver supports them—often numerically stabler than naive big-M.

Big-M discipline

1. Derive M from physical or logical bounds, not 1e6 habit 2. Use tightest valid M per constraint, not one global constant 3. Test relaxation value—if binaries fractional at root, M likely loose 4. Consider indicator constraints (Gurobi/CPLEX) or OR-Tools literals

Valid inequalities and tightening

Document any manual cuts so maintenance engineers understand binding logic.

Decomposition (conceptual)

Prototype on small instances before committing to custom decomposition code.

QP and conic notes

• Confirm convexity for global QP optimum
• Distance objectives often linearized for MILP (Manhattan) or handled in routing engines
• Second-order cone useful for robust norms—use when solver license includes conic

OR algorithm developer scope

Table of contents

1. Purpose 2. Terminology 3. In scope 4. Out of scope 5. Problem taxonomy 6. Roles and RACI 7. Handoffs

Purpose

Define operations research and optimization engineering—formulating decision problems, implementing solver-backed models, and delivering production-grade optimization services.

This skill covers mathematical modeling, algorithm selection, solver integration, and OR-specific production patterns—not general software platforms, ML prediction pipelines, or warehouse/ERP product features.

Terminology

In scope

Out of scope

Problem taxonomy

Roles and RACI

Handoffs

• To `data-scientist` when the core task is prediction/forecast accuracy without explicit optimization over decisions
• To `supply-chain-manager` when deliverable is operating model, policy, or supplier process—not solver-backed plan
• To `simulation-software-engineer` when building a reusable simulator runtime (time stepping, sensors, replay)
• To `senior-software-engineer` when work is primarily application logic without OR formulation ownership
• From `analytics-data-engineer` when curated tables and metrics feed parameters; OR owns model and solve

Problem formulation and data

Table of contents

1. Formulation checklist 2. Notation template 3. Hard vs soft constraints 4. Data preparation 5. Validation rules 6. Uncertainty hooks 7. Common formulation errors

Formulation checklist

1. Decision variables—what is chosen (assign, route, schedule, produce)? 2. State—what is known vs decided each period? 3. Objective—single scalar; document weights for multi-criteria cases 4. Constraints—capacity, precedence, compatibility, time windows, minimum service 5. Parameters—demand, costs, travel times, capacities, yields (with units) 6. Feasibility policy—allow slack? penalty costs? reject infeasible inputs? 7. Optimality target—prove optimal, or accept gap/time limit?

Notation template

Document before implementation:

Sets:    I (items), J (locations), T (periods), K (vehicles)
Params:  d_i (demand), c_ij (cost), Q_k (capacity), [τ_ij] (time)
Vars:    x_ij ∈ {0,1} (assign i→j), y_kt ≥ 0 (inventory)
Objective: min Σ c_ij x_ij + holding costs
s.t.     Σ_j x_ij = 1          ∀i   (each item assigned once)
         Σ_i d_i x_ij ≤ Q_j    ∀j   (capacity)
         ...

Keep indices consistent across data files, code, and reports.

Hard vs soft constraints

Penalize slack in objective units comparable to primary cost—document penalty calibration.

Data preparation

Validation rules

Run before every solve:

• Dimensional analysis—cost = rate × quantity; time matrices symmetric if required
• Bounds—capacities ≥ 0; demands non-negative unless returns modeled
• Coverage—every demand node has supply or penalty; every job has eligible resources
• Graph checks—no disconnected required arcs; unreachable customers flagged
• Feasibility screen—total demand ≤ total capacity (necessary, not sufficient)

Uncertainty hooks

Route full sim platform builds to simulation-software-engineer; keep OR-level scenario loops lightweight.

Common formulation errors

Routing, scheduling, and networks

Table of contents

1. Network flows and assignment 2. Vehicle routing (VRP) 3. Scheduling 4. Resource allocation 5. Inventory and production planning 6. Method selection

Network flows and assignment

Check: conservation of flow, capacity on arcs, cost sign convention.

Vehicle routing (VRP)

Exact MIP: viable only for small instances; use for benchmarks.

Metaheuristics / OR-Tools routing: default for operational scale—document destroy/repair or search operators used.

Output contract: routes as ordered node lists, arrival times, load profiles, unassigned customers with reason codes.

Scheduling

Horizon discretization: choose time buckets vs continuous—trade model size vs accuracy.

Objective: minimize makespan, tardiness Σ w_i T_i, or weighted completion.

Resource allocation

• Bipartite matching: one-to-one assign with preferences/costs
• Generalized assignment: agents with capacity, tasks with demand—MIP
• Fairness: max-min or equity constraints—may need extra variables or multi-objective scalarization

Coordinate with product SLOs—explain trade-off between cost optimality and fairness.

Inventory and production planning

Link periods: inventory_t = inventory_{t-1} + production − demand.

Method selection

Route warehouse execution software to wms-developer; OR may output plans (waves, routes) as inputs, not WMS code.

Solver integration and production

Table of contents

1. Solver landscape 2. Selection criteria 3. Model lifecycle 4. API and service patterns 5. Timeouts and fallbacks 6. Warm starts and incremental solve 7. Infeasibility diagnosis 8. Sensitivity and reporting 9. Observability 10. Licensing and deployment

Solver landscape

Treat solver choice as non-functional requirement—license, support, and performance on your model class.

Selection criteria

Model lifecycle

1. Version formulation (git tag) separate from code 2. Serialize instance files (JSON, LP, MPS) for reproducibility 3. CI: small golden instances—objective within tolerance, feasible 4. Staging: full-size nightly with time limits 5. Production: pinned solver version; monitor regressions

API and service patterns

Response payload: status, objective, gap, runtime, solution, dual summary (optional), warnings, model_version.

Validate inputs before solver call—return 400 with structured errors, not opaque solver crashes.

Timeouts and fallbacks

Never block HTTP workers unbounded—thread pool or job queue for long solves.

Warm starts and incremental solve

• MIP start: inject prior x values; verify feasibility
• LP basis (advanced): speed re-solve after small rhs changes
• Rolling horizon: fix early periods, optimize tail
• Real-time: limit changed variables; short time limit

Log whether warm start improved time to first incumbent.

Infeasibility diagnosis

Deliver business-readable conflict—e.g., “capacity week 12 + minimum service” not only row IDs.

Sensitivity and reporting

• Objective coefficients: allowable increase/decrease (LP)
• RHS shadow prices: interpret only for valid LP segments
• Scenario compare: side-by-side objectives and key decisions
• Benchmark table: method, gap, time, nodes (MIP)

Observability

Alert on gap regression or infeasibility spike after deploy.

Licensing and deployment

• Run license server or cloud token per vendor docs
• Pin solver version in container images
• Isolate CPU and memory limits for solve workers
• Do not embed license secrets in repos—use env/secret store

Coordinate with `senior-software-engineer` for service mesh, auth, and deployment; OR owns model correctness and solve SLOs.