MES system with an AI cascade

In the order line description, a salesperson typed technological information as free text: lengths, quantities, allowances, auxiliary cuts and extra annotations. The same meaning could be written in many ways, with typos and no structure. I built a custom MES-class system that turns such a description into production data and then calculates the delivery date strictly in working days, without uncontrolled writes to the ERP database.

• 01The input data was unstructured and inconsistent, so a simple rule-based parser was not robust enough.
• 02An error in the number of cuts or in dimensions translated directly into workstation load and the delivery date declared to the customer.
• 03Running a language model for every order line would generate an unacceptable cost at this scale of operations.
• 04The delivery date had to respect the real working calendar, not just calendar days.
• 05The ERP database was business-critical, so reads had to stay read-only and any write-back strictly controlled.

I designed a system that works as its own layer next to the ERP and performs two tasks: extracting production data from the free-text description, and calculating the delivery date in working days, taking the calendar and process logic into account. The heart of the solution is a cascade of six layers. Each subsequent layer is more expensive or slower, so it runs only when the previous one cannot resolve the case.

• 01Normalization: industry dictionaries, units, removing noise and common typos.
• 02Deterministic rules: description patterns that can be recognized with full certainty.
• 03Memory of approved resolutions: previously confirmed cases used as a knowledge base.
• 04Local ML model: classification of cases similar to known ones, with no external API cost.
• 05Language model as a judge: called only for the unresolved remainder, with a cost limit and temperature set for deterministic behavior.
• 06Human verification: an exception queue that closes ambiguous cases and at the same time feeds further learning of the system.

Regardless of where a decision comes from, the result passes through a physical rules validator. It checks admissible dimension ranges, the balance of allowance and kerf, and the consistency of the operation totals. Thanks to this, the model cannot emit a result that contradicts the logic of the process.

The ERP remains the source of business truth. The MES system performs wide reads only in read-only mode and keeps all of its own state outside the ERP.

• 01Input data is synchronized incrementally.
• 02The parsing engine and the scheduling engine run in the .NET 8 application layer.
• 03Results, models, queues and the audit log go to the system's own database.
• 04Calls to the paid language model API are conditional and constrained by cost control.
• 05The write-back to the ERP covers exactly one controlled field: the order delivery date and line dates.

This is not a one-off model deployment. An operator approves or corrects the result in a verification screen, and only an approved record feeds the training set and the pattern memory. The system therefore learns from its own verified data, not from random predictions.

• 01About 67% of order lines are resolved deterministically, without involving the ML model and without the paid API.
• 02The knowledge base covers over 200 thousand approved records, reduced to about 34 thousand unique semantic signatures.
• 03The working calendar covers 3,287 days for the years 2023-2031, including 117 statutory holidays.
• 04Within the verified scope of the project, 100% of the dates in the examined pool of open orders fell on a working day.
• 05Changes are covered by automated regression tests and rolled out in stages with result parity control.
• 06Paid API calls are limited to the unresolved remainder only, with a cost limit and an emergency cut-off switch.

• 01A cost cascade instead of one "magic model". Most of the traffic is handled by local, deterministic layers.
• 02A domain validator above the model. Even an accurate language prediction cannot bypass the physical rules of the process.
• 03ERP inviolability. Reads are wide but read-only. The application's own state is separated, and the write-back has a minimal, strictly auditable scope.
• 04Learning from approved data. Only a record verified by a human enters the pattern memory and the training set.