How EDGEBIC Resolves Setup Time: The Five-Level Chain

Every operation EDGEBIC by User Solutions schedules gets its setup time from one of five checks, run in a fixed order, first hit wins. The chain runs from cold start through same-product, product-level matrix, family-level matrix, and finally a fallback to the routing step's own number. Because the answer is recorded on every scheduled row, any setup hour on the plan can be traced to the rule that produced it. This post walks the chain, the traversal that finds the previous product, and the two places the mechanism has to be careful.

For what the matrix is, read the setup matrix explained. For how to build one, see how to build a setup matrix. This is what happens after you have.

The Chain

When the engine schedules a non-material operation, it needs one number: how many hours to reserve for setup before the run hours begin. It gets that number like this:

Two things about the order are worth pausing on.

Level 3 beats level 4 unconditionally. A product-level override is consulted before the family rule and stops the search when it hits. That is what makes overrides useful: red-to-black can cost 90 minutes while every other light-to-dark pair keeps the family's 60, without touching the family grid at all.

Level 1 does not return zero. A cold start means there is no changeover to price, but the machine still needs its initial preparation, so the routing step's setup applies. Only level 2, the same product back to back, genuinely returns zero. Confusing the two is how a first-job-of-the-day gets planned with no setup at all.

Before any of this runs, the engine checks whether a matrix exists at all. With no cells entered anywhere, the whole mechanism is skipped and the flat routing setup is used exactly as it was before the feature existed. That short-circuit is why turning the matrix on cannot change a schedule until somebody enters a cell.

Finding the Previous Product

Levels 2 through 4 all depend on one question: what did this machine run last? The engine answers it two different ways depending on whether it is planning fresh or rescheduling against actuals.

On a reschedule, actuals win. The engine consults what actually completed on that work center and instance according to the shop floor record. If white finished on the booth on Tuesday afternoon, Wednesday's first job is priced as a changeover from white. This matters because a reschedule clears and rebuilds all future allocations, so the planning state has no memory of Tuesday. Anchoring to the floor is what keeps the first setup after every reschedule honest. The wider rule that recorded work is never re-planned is covered in the partial completion reschedule walkthrough.

When planning, the engine scans the machine's allocations. It looks for the allocation ending latest at or before the new job's earliest start. If it finds one, that is the predecessor. If it does not, it falls back to the most recently placed allocation on that machine regardless of timing.

That second fallback exists for a specific reason. A job's start date in EDGEBIC is an earliest-start floor rather than a chronological cursor, so many jobs legitimately share the same one. A strict "must end before this moment" filter would cold-start every job whose floor matched another job's, and a schedule full of cold starts prices no changeovers at all. The fallback keeps the chain meaningful when timestamps tie.

If neither lookup finds anything, the answer is genuinely a cold start: nothing has run here yet.

Resolve Once, Use Twice

The resolved setup is computed a single time per operation per scheduling pass and then held for the rest of that pass. That is not an optimization, it is a correctness requirement, and the reason is worth understanding because it links two features that look unrelated.

Lot streaming needs the upstream setup time to compute when the first transfer batch is ready: the gate is setup plus batch size times hours per piece. So the streaming calculation asks for the setup value a second time, after the operation has already been placed.

By that moment, the operation is itself the most recent allocation on the machine. A fresh lookup would find the step's own product as the "previous" product, hit level 2, and return zero. The overlap math would then behave as though setup had never happened, releasing the downstream step early by exactly the changeover time. Caching the first resolution and reading it back avoids the trap entirely.

The cache is cleared between passes, so a second job's resolution can never inherit the first job's answer. That reset is the invariant that keeps repeated scheduling runs producing the same numbers.

A Worked Resolution

A paint booth with two families: Light (white, cream) and Dark (black, dark grey). The family grid holds light-to-light 0, light-to-dark 60, dark-to-light 240, dark-to-dark 0. The routing step carries a flat 30-minute setup as a fallback. Three jobs in due-date order: white, black, white.

Job 1, white. Nothing has run on the booth. Level 1 hits: cold start, 30 minutes from the routing step, 0.5 hours reserved.

Job 2, black. Previous product is white.

1. Previous product exists, so level 1 does not apply.
2. White is not black, so level 2 does not apply.
3. No product-level cell for white-to-black.
4. White is in Light, black is in Dark, and the light-to-dark cell holds 60. Hit. 60 minutes becomes 1.0 hour, source: family matrix.

Job 3, white. Previous product is black. Levels 1, 2, and 3 all pass through, and the dark-to-light cell holds 240. Four hours reserved, source: family matrix.

Total planned changeover: 30 + 60 + 240 = 330 minutes, which is what the floor actually spends.

Now add one override: red belongs to Light, but red-to-black needs an extra flush at 90 minutes. Schedule a red job followed by a black one and level 3 hits immediately with 1.5 hours. The family grid is never consulted, and the row's reason reads "Product matrix Red to Black: 90 min."

What Honest Numbers Look Like

The same three paint jobs, scheduled three ways, show what the chain buys you:

Scenario A and Scenario C finish at the same time on paper, and only one of them is real. That is the whole argument for the chain: A is a plan that cannot be executed, C is a plan that can. Getting from B to C is a sequencing decision rather than a software one, and the paint-booth walkthrough works six jobs through it.

The Audit Trail

Every scheduled row carries both the source code and a readable sentence. Two additional sources appear that are not part of the five-level chain:

• Historical completed. The operation already ran, so its setup is preserved from the record rather than re-resolved. Recorded work is never re-planned.
• Mirrored from parent. A dependent-parallel operation running in lockstep with its parent inherits the parent's changeover by definition, so the resolver does not run independently for it. The synchronized case is covered in the multi-spindle example.

The job view renders matrix-driven rows at full brightness and the rest muted, which turns the audit trail into a coverage report. A plan where most rows are muted is telling you the matrix is not describing the transitions that are actually happening.

Two Places to Be Careful

Minutes versus hours. Matrix cells are stored in minutes and the engine works in hours, with the conversion done once inside the resolver. Enter a value in decimal hours by mistake and you are wrong by a factor of sixty: a one-hour changeover typed as 60 is correct, and typed as 1 it becomes one minute. The field is labeled in minutes for exactly this reason.

Both products need families. Level 4 requires the previous product and the current product to both have a family assigned. If either is missing, the family lookup is skipped silently and the routing default applies, which produces a matrix that looks complete and does nothing. There is no warning for this today, so the audit column is your detection mechanism: an unexpected routing-default row on a transition you thought was covered almost always means a missing assignment.

Where This Feeds

The resolved setup does not just reserve hours. It flows into the operation's total time, which drives the multi-shift allocation, which drives the finish date, which drives every downstream step. It also feeds the lot streaming gate, so a longer changeover pushes the transfer batch later and shrinks the overlap. That interlock is covered in transfer batch versus flow overlap.

Which is the practical case for getting the chain right: setup time is not a line item on a report, it is an input to the dates you promise customers. Setup matrix mistakes covers the configurations that leave the chain resolving to fallbacks, and the complete guide to EDGEBIC shows where changeover sits among the engine's other decisions.

Bring one machine's worth of changeover times to a demo of EDGEBIC and we will trace the chain on your own transitions.