Machine Eligibility Belongs in the Schedule Engine

Every planning session opens with the same quiet question: which machines can run this product at this stage? It is asked once per product, once per stage, once per schedule, and it is answered from memory, or from a spreadsheet everyone has seen and nobody owns. The answer is plant fact. It does not change with the workload, the week, or the planner. It is a fixed property of the equipment and the product class. Yet in many plants that fact lives outside the scheduling engine, and every schedule re-applies it by hand.

What a schedule inherits when eligibility lives outside the engine

Every schedule depends on recall. The mechanism is ordinary: the planner builds a schedule and, at each stage, consults the same unmodeled source, a head, a colleague, a sheet of notes. The check is quick, so it is repeated constantly, and every repetition is a chance for the answer to drift from the plant as it actually is. The check also consumes planning time on every schedule, even when the answer is right, because it is re-applied to every stage in the route and every class on the schedule. A re-run repeats the check. A new planner repeats it without the old context. An unfamiliar product class gets a best guess instead of a verified answer.

When the guess is right, nothing seems wrong, which is exactly why the failure stays invisible. The schedule assigns work a machine cannot run, and the mismatch surfaces only when the schedule meets the line and the machine cannot take the work. By then the time is spent and the schedule has to be repaired. Nothing here is exotic, and none of it requires bad people or bad plants. A schedule that depends on one person's recall is fragile, and a plant that carries eligibility in an unmodeled spreadsheet has made recall a permanent input.

Eligibility is structural knowledge

Eligibility is structural knowledge, and structural knowledge belongs in the model. A scheduling engine can only respect the constraints it is given. Give it no eligible set, and it has no way to treat a machine as anything but a candidate for any product. That is the failure mode of the unmodeled spreadsheet, reproduced. A better planner or a stricter checklist does not fix it. The fix is to stop treating eligibility as schedule content and start treating it as plant structure.

Two questions hide inside the word assignment. The first is what CAN run: the eligible set, the machines that can actually process this class at this stage. The second is what WILL run: the machine assignment within that set. They are different in kind. What can run is a fact about the plant. What will run is the schedule. The plant decides eligibility once. The engine should carry it and honor it on every schedule that follows.

How the engine models it

Eligibility enters the engine as a capability record, one machine at a time. A machine carries a line speed for the product classes it can run as a flow stage, and a batch size with a batch cycle time for the classes it can run as a batch stage. Those entries are the record. Products inherit capability from their class, so eligibility is defined per class and per stage, never globally: a class routes only through the stages it requires, each machine belongs to exactly one stage, and there is no per-product capability. The entries say two things: that the machine can process the class at that stage, and how long it takes. When the entries exist, the machine is a candidate for the class at that stage. When they do not, it is not.

The enforcement follows directly from the record. In Auto and Semi-Auto modes the engine restricts machine assignment to machines actually capable of the product at that stage. A machine with no capability entry for a class is not a candidate for that class, and other classes still flow across the full machine pool. There is no separate eligibility rule layered on top; the restriction falls out of which entries exist.

The optimization then works inside the eligible set. Auto mode optimizes the production sequence and the machine assignments together. Semi-Auto mode holds the production sequence fixed and optimizes the machine assignments within it. Both minimize total production time. One fact stays outside the model: why a machine can or cannot run a class. That reason is decided in the plant and entered as capability. Capability is a static, configured fact. The engine does not measure it and does not learn it.

What shifts for the planner

With the eligible set implied by the entries, the planner's job shifts. Planning time goes to the decisions the planner owns: which jobs to run, and in Semi-Auto the production sequence they run in. The engine holds what can run, so the planner does not re-verify it on every schedule. What should run starts as a planning judgment; the engine then turns that intent into a workable schedule, in Auto by also choosing the production sequence, in Semi-Auto by holding the sequence fixed and optimizing machine assignments within it. Either way the objective is the same: minimize total production time.

It is worth being precise about the boundary of that shift, because it is real only inside it. Restricting the candidate set as part of a search, and optimizing the assignment within it, are behaviors of Auto and Semi-Auto modes. Manual mode runs no algorithm, so neither happens there, but the same machine-compatibility check still runs as per-row validation: enter a machine that cannot process the product class and the system rejects the row. Nor is eligibility the whole assignment problem. It is one structural fact among several the engine models: changeovers, calendars, availability, and material supply all shape real assignments. The point is not that capability is the only constraint. It is that a constraint the engine does not model is a constraint the planner carries by hand.

One obligation comes with the shift. Eligibility is expressed by what is on file, so the entries are a working document. Capability data must be entered and maintained like any other plant configuration. The engine does not infer a machine's capability from anywhere else, and a capability that was never entered leaves the machine out of the eligible set. When the omission is deliberate, that is the model working as intended. When it is not, it is why the data must be kept current.

Where does eligibility live in your plant

So ask the question where it matters: when a planner needs to know which machines can run this class at this stage, where does the answer come from? If it comes from a head or a spreadsheet, the schedule inherits recall, one re-application at a time. If it comes from the model, the plant has decided once, and every schedule honors that decision. The same test applies to any scheduling tool you evaluate: is the eligible set an input the engine honors, or a detail the planner must re-apply by hand? Decide eligibility once, in the plant, entered as capability. Then let the engine honor it on every schedule.