# 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.