Home/Offers/Manufacturing & Industrial/Factory Production Optimisation API

Manufacturing & Industrial

Factory Production Optimisation API

Your line has a bottleneck. It moves depending on product mix, shift and what broke last week, which is why the schedule built on Friday rarely survives Tuesday.

Manufacturing execution system vendors
Plant operations teams
Industrial software platforms
Contract manufacturers

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Production scheduling in most plants is a planner with a spreadsheet, long experience and a telephone. That combination is better than it sounds — the planner knows which machine struggles with which product and which changeover eats half a shift. It also does not scale, does not survive the planner being on leave, and cannot evaluate forty alternative sequences before committing to one.

Meanwhile the data needed to do better is being recorded and ignored. Machine states, cycle times, changeover durations, downtime reasons, scrap rates and order throughput sit in the MES and the historian. From those you can establish where the constraint actually is over time rather than where everyone believes it is, and the answer is frequently not the machine with the reputation.

The modelling splits cleanly into two halves. Forecasting throughput and predicting where the constraint will land next week is a statistical problem, and a tractable one. Producing a schedule is an optimisation problem with awkward real constraints — changeover sequence dependencies, labour availability, material arrival, tooling, maintenance windows. Those two halves should be built as separate components, because conflating them produces a system that is neither a good forecast nor a usable schedule.

Who buys this

Manufacturing execution system vendors, Plant operations teams, Industrial software platforms, Contract manufacturers

Category: Manufacturing & Industrial

What the API returns

What comes back

Bottleneck identification over time, with the constraint ranked and attributed
Throughput forecasts per line and per product family with confidence intervals
Predicted constraint shift under a proposed product mix or order book
Changeover cost matrix learned from observed durations rather than standard times
Schedule recommendations that respect sequence, labour, material and maintenance constraints
Scenario comparison for alternative sequences, shift patterns or order priorities
Downtime and scrap attribution by machine, product, shift and cause
Explicit infeasibility reporting when the requested plan cannot be met, with the binding constraint named

Endpoints

Method	Path	Returns
GET	/v1/lines/{id}/bottleneck	Current and historical constraint analysis for a line
POST	/v1/forecast/throughput	Throughput forecast for a line and horizon
POST	/v1/schedule/optimise	Produce a schedule for an order set under stated constraints
POST	/v1/schedule/evaluate	Score a schedule your planner has already built
POST	/v1/scenarios/compare	Compare alternative mixes, sequences or shift patterns
GET	/v1/changeovers/matrix	Learned changeover durations between product states

Request and response

illustrative

Request

{
  "line_id": "line_03",
  "orders": [
    { "order_id": "so_88121", "product": "P-440", "quantity": 12000, "due": "2026-10-28" },
    { "order_id": "so_88140", "product": "P-118", "quantity": 4200,  "due": "2026-10-26" },
    { "order_id": "so_88155", "product": "P-440", "quantity": 8000,  "due": "2026-11-02" }
  ],
  "constraints": {
    "shifts": ["mon-fri 06:00-22:00"],
    "maintenance_windows": [{ "asset": "press_02", "from": "2026-10-24T06:00:00Z",
                              "to": "2026-10-24T14:00:00Z" }],
    "labour": { "operators_available": 6 }
  },
  "objective": "minimise_late_orders"
}

Response

{
  "line_id": "line_03",
  "generated_at": "2026-10-21T16:02:00Z",
  "bottleneck": {
    "current": { "asset": "press_02", "utilisation": 0.94,
                 "share_of_constraint_hours_30d": 0.61 },
    "predicted_next_period": { "asset": "packer_01",
      "reason": "P-118 volume raises packing demand above press capacity" }
  },
  "throughput_forecast": [
    { "week": "2026-W44", "units": 19400, "ci": [17900, 20600] },
    { "week": "2026-W45", "units": 21100, "ci": [19200, 22800] }
  ],
  "schedule": [
    { "sequence": 1, "order_id": "so_88140", "start": "2026-10-22T06:00:00Z",
      "finish": "2026-10-23T11:20:00Z", "changeover_hours_before": 0.0 },
    { "sequence": 2, "order_id": "so_88121", "start": "2026-10-23T12:40:00Z",
      "finish": "2026-10-27T09:10:00Z", "changeover_hours_before": 1.33 },
    { "sequence": 3, "order_id": "so_88155", "start": "2026-10-27T10:00:00Z",
      "finish": "2026-10-30T18:40:00Z", "changeover_hours_before": 0.0 }
  ],
  "late_orders": [],
  "changeover_hours_total": 1.33,
  "binding_constraints": ["press_02 maintenance window", "operators_available"],
  "note": "Sequencing P-440 orders consecutively avoids a second 1.3h changeover."
}

Where the data comes from

MES and production records	Order, batch and operation records with start and finish times — the core input
Machine state and historian data	Running, idle, blocked, starved and down states, which is where constraint analysis actually comes from
Downtime and reason codes	Recorded stoppage causes; the quality of the reason coding determines how useful attribution can be
Changeover and setup records	Observed durations between product states, which differ substantially from the standard times in the routing
Quality and scrap records	Yield by product and machine, since effective capacity is not nameplate capacity
Order book and material availability	What has to be made and when the inputs arrive, without which a schedule is fiction

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Constraint identification from machine state sequences — blocked and starved states upstream and downstream — rather than utilisation alone, because the busiest machine is often not the constraint
Changeover matrices learned from observed transitions, since routing standard times are frequently years out of date and systematically optimistic
Throughput forecasting that separates stable capacity from mix effects, so a forecast miss can be attributed to one or the other
Scheduling as constrained optimisation with sequence-dependent setups, solved to a time budget that fits a planner's workflow rather than to proven optimality
Effective-capacity modelling that incorporates yield, so a 94 percent first-pass line is not planned as though it were perfect
Explicit infeasibility output naming the binding constraint, because a planner needs to know what to go and negotiate rather than receiving a quietly-relaxed plan
Backtesting of forecasts and schedules against what the plant actually achieved, reported as realised error rather than solver objective value
Drift monitoring on cycle and changeover times, which move as tooling wears, operators change and products are reformulated

What it changes for the business

Changeover hours recovered

Sequencing against learned changeover costs removes setup time the standard times never showed.

Constraint attention in the right place

Measured constraint analysis frequently moves investment away from the machine everyone blamed.

Schedules that survive contact

Plans built on observed capacity and real yield need less firefighting mid-week.

Planning continuity

The planner's knowledge becomes an explicit constraint set rather than something that leaves with them.

How it fits into your product

How it embeds

Reads from your MES, historian or ERP on a schedule, or accepts pushed records
Schedules returned as structured output your MES or planning screen can display and edit
Evaluate-only mode so a planner's own schedule can be scored before anything is automated
Scenario endpoints for mix, shift pattern and capital investment questions
On-premise deployment, which is normal where production data stays inside the plant network
Per-site and per-line scoping for multi-plant groups and contract manufacturers

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Will this replace our planner?

No, and the builds that assume it will tend to fail. A planner holds constraints that are nowhere in the data — which customer will tolerate a slip, which operator can run the old press, what maintenance really needs. The useful product gives them evaluated options and surfaces the changeover and capacity arithmetic they cannot do in their head. We would normally start in evaluate-only mode, scoring their schedules, because that builds the trust that any later automation depends on.

How good does the downtime reason coding need to be?

Better than most plants have, and this is worth confronting early. If half the stoppages are coded as “other”, attribution is guesswork. Bottleneck identification and throughput forecasting still work from machine states without good reason codes; cause attribution does not. We would measure the coding quality during discovery and tell you which outputs it supports.

Can it schedule across several lines or plants?

Yes, though multi-plant scheduling adds transfer times, material positioning and plant-specific capability, and the problem grows quickly. We would normally prove the approach on one line, then extend. A proposal that starts with a whole-group optimiser is a proposal with a long gap before anything useful ships.

What if the schedule is infeasible?

The API says so and names the binding constraint rather than returning a plan that quietly breaks a maintenance window or assumes seven operators. Infeasibility is useful information — it tells the planner exactly what to go and change.

How accurate are the throughput forecasts?

Good over a week or two on stable mix, noticeably worse across a mix change or after a line modification. The API returns intervals rather than point values for that reason, and we report measured error from backtesting instead of quoting an accuracy figure that would not survive your product mix.

All Manufacturing & Industrial offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers