example/README.md

Example data: one linked run

These four files come from one run of the production scheduling service on its demo data, captured on 2026-10-02. The run used a local deployment of the same build as the hosted service. The names in the data were replaced with neutral ids (see below). Everything else is exactly as the service produced it.

Before this capture, five waste rates in the demo data were corrected. They had been entered as percentages (10, 20 and 50) where the service expects the fraction of a task's input that is lost. They are now 0.10, 0.20 and 0.50. Nothing else in the demo data was changed.

Stage 1 is the planning model (mixed-integer programming, MIP). Stage 2 is the scheduling heuristic. The main page, ../README.md, explains both.

File	Stage	What it is	Used by
stage1_mip_input.json	1	The stage 1 input that the service built from its demo orders	Body of POST /api/scheduling/planFromJSONNODB
stage1_mip_output.json	1	The plan that stage 1 returned in that run	Compare with the live stage 1 answer
stage2_heuristic_input.json	2	The stage 2 input that the service built from that plan, in the same run	Part file of POST /api/scheduling/scheduleFromJSONNODB
stage2_heuristic_output.json	2	The schedule that stage 2 produced in that run	Compare with the live stage 2 answer

stage2_heuristic_output.json holds only the schedule object (id, assignments). The live endpoint returns the same object inside schedule, next to dh, mna, sr and assignmentCount. The captured run used the pipeline's fixed parameter values: dh=2, mna=100, sr=10.

How the two stages link

• Stage 2 resource _<n> is stage 1 machine <n>. Its name is Machine-M<n>.
• Each stage 2 task is a task order that the service created for one stage 1 task. Each stage 2 job is a job order for one stage 1 job. Their names carry the stage 1 ids: task Task-T<n> is stage 1 task <n>, and job Job-J<n> is stage 1 job <n>. The stage 2 ids (_30, _75, ...) are only the internal keys of those orders.
• Only process plans with production above zero reach stage 2. Order 10 asks for 3000 units of product 2 and 2000 units of product 3. Product 3 has two process plans, and the MIP made all of it through plan 4. So plan 3 (job 3, tasks 3, 6 and 7) has no stage 2 tasks.
• Each stage 2 task has exactly one suitable resource: the machine the MIP chose for it (where task_assignment is true).
• The stage 2 precedence constraints (which task must finish before another starts) are the stage 1 task predecessors within each job.

Stage 2 task	Stage 2 job	Stage 1 order	Product	Process plan	Job	Task	Machine	Stage 1 duration (h)	Stage 2 duration (s)
_76	_30	10	2	2	2	1	1	33.333333333333336	120000
_75	_30	10	2	2	2	2	2	33.333333333333336	120000
_79	_31	10	3	4	4	8	1	22.22222222222222	80000
_78	_31	10	3	4	4	9	3	20.0	72000
_77	_31	10	3	4	4	10	3	20.0	72000

Rows are in precedence order within each job. Stage 1 duration is task_duration. Stage 2 duration is operationtimeperbatchinseconds: the stage 1 duration × 3600, rounded down. In the stage 2 output, the durationinmilliseconds of each assignment is longer. It covers the time from start to end, including any non-working periods in between.

Task 8 runs on machine 1, which loses 10% of its input for that task. It takes in 2,222.2 units of product 1 and passes 2,000 on, so 222.2 units are lost. All other tasks in the plan lose nothing.

What was changed to anonymize the data

Only stage2_heuristic_input.json was edited:

• id: the service's label held an internal schedule number and the capture time. It was replaced by "example".
• The name of each of the 3 resources, 2 jobs and 5 tasks: the demo data's names were replaced by the neutral ids above (Machine-M<n>, Job-J<n>, Task-T<n>).

Not changed:

• the workcenter's name and description, Generic Workcenter, which the service writes into every run;
• all ids, quantities, costs, prices, rates, stock, durations, dates and non-working periods;
• the set-up codes, which are empty, and the set-up matrix, which has no entries. The example has no set-up times.

The two stage 1 files hold only ids and numbers. The stage 2 output holds only ids, times and durations (its id, planning output, is fixed text). So all three are exactly as captured. No customer, order, product, workcenter or shift name from the demo data appears in any of the four files.

Run times measured at capture

Each HTTP call was run once on the local deployment, through its gateway, and timed from request to answer:

Call	What runs	Time (s)
GET /api/scheduling/{id}/optimize-schedule (the captured run)	Stage 1, job order creation, stage 2 and saving the result	1.14
POST /api/scheduling/planFromJSONNODB with stage1_mip_input.json	Stage 1	0.09
POST /api/scheduling/scheduleFromJSONNODB?dh=2&mna=100&sr=10 with stage2_heuristic_input.json (after anonymization)	Stage 2	0.15

The stage 1 call returned exactly the plan in stage1_mip_output.json. The stage 2 call scheduled all 5 tasks, but this time in a different schedule from stage2_heuristic_output.json. That can happen, because the heuristic samples at random. Times on the hosted service will differ.