TOC Buffers and Direction Precedence in EDGEBIC

TOC buffer scheduling in EDGEBIC has two halves: how wide the three protective buffers are, and which scheduling direction wins when several rules could apply to the same job. Both are deterministic, both are computed from data you control, and neither is a black box. This post covers the arithmetic behind each with worked numbers, using EDGEBIC by User Solutions.

For the concept, read TOC anchor scheduling explained. For the configuration steps, read how to flag and schedule around a bottleneck. For a single job traced with dates on a Gantt, read the anchor scheduling walkthrough.

Part One: What Happens When an Anchor Fires

Before the buffers make sense, the shape of an anchored run has to be clear.

Detection. The engine looks for an existing schedule row on this job carrying a target start date, then matches that row's work center to a routing step. Both must exist, which is why marking a work center as a bottleneck does nothing on its own and why a brand new job with no prior schedule rows cannot be anchored yet.

Constraint characterization. With an anchor step confirmed, the engine computes a load factor for every work center in the routing:

load factor = (run hours × quantity + setup) ÷ (shift hours × instances × utilization %)

If the anchored work center holds the highest load factor in the routing, it is confirmed as the genuine constraint for this job at this quantity. That single result decides which of two buffer regimes applies. Note that it is a per-job judgment: a resource can be the tightest one for a 200-piece order and not for a 20-piece one, which is exactly why the check runs per job rather than being read off the work center flag. For the wider analysis of picking a constraint in the first place, see how to identify production bottlenecks.

Routing split. The routing is divided into operations that come before the anchor and operations that come after it. Three methods are tried in order: routing level first, then sequence number, then the successor links between steps. At least one of those has to be populated, which is a good reason to keep sequence numbers in genuine order when you build a routing.

Three passes. The constraint is scheduled first at maximum priority. Upstream operations are then planned backward from the pin. Downstream operations are planned forward from the constraint's finish. Every subordinated operation runs at reduced priority so it cannot compete with the constraint for shared capacity.

Part Two: Sizing the Three Buffers

Buffers are off by default. When you enable them, the sizing depends on whether the anchored work center was confirmed as the tightest resource.

When the anchor is the genuine constraint

The engine sums the work content on each side of the anchor, where each operation contributes run hours times quantity, plus setup, plus queue time. Then:

Proportional sizing is the point. A big job with a long upstream path carries a big cushion because there is more variation to absorb. A short job carries a small one.

When the anchor is not the tightest resource

Pinning a target date on a work center that is not the highest-load resource for that job still activates anchor scheduling, because the pin is the trigger. But the engine sizes conservatively instead:

That is the right behavior. Protecting a resource that has slack is not worth days of earlier release, and the small fixed cushions still absorb ordinary noise.

One boundary worth knowing: the comparison between the anchor's load factor and the highest load factor is exact. An anchor at 1.80 when another work center sits at 1.81 is not confirmed as the constraint, and the fixed buffers apply. If your anchor is close to but not quite the top, check the load numbers before assuming the buffers are wrong.

Part Three: A Worked Job

Two hundred precision shafts. The heat-treat oven is the constraint, single instance, long cycle. The planner pins the oven to Monday 07:00.

The routing:

Load factors confirm the choice:

The oven is the highest by a wide margin, so proportional buffers apply.

Without buffers

The constraint takes its pinned slot. Upstream operations chain backward, each one's latest acceptable start being the running deadline minus its duration:

The oven starts exactly on target and nothing arrives early. It is also completely exposed: any delay on the lathe pushes the mill, and any delay on the mill starves the oven.

With buffers on

Upstream path: 19.0 + 11.5 = 30.5 hours. Downstream path: 12.5 + 4.0 = 16.5 hours.

Constraint buffer = 30.5 × 0.50 = 15.25 h
Shipping buffer   = 16.5 × 0.25 = 4.125 h   (above the 2 h floor)
Feeding buffer    = 30.5 × 0.10 = 3.05 h    (applied to Mill-2 only)

Backward, from a deadline that is now 15.25 hours earlier than the pin:

Upstream deadline = Mon 07:00 − 15.25 h = Sun 15:45
Mill-2 duration   = 11.5 + 3.05 feeding buffer = 14.55 h
Mill-2 start      = Sun 15:45 − 14.55 h = Sun 01:12
Lathe-1 start     = Sun 01:12 − 19 h    = Fri 06:12

Forward, from a finish that now waits out the shipping buffer:

Downstream start = Tue 05:00 + 4.125 h = Tue 09:08
Grind-1          = Tue 09:08 to Tue 21:38
Inspect          = Tue 21:38 to Wed 01:38

Read the difference on one line: the first upstream operation releases roughly 18 hours earlier, and in exchange the oven can absorb an entire bad shift upstream and still start on time. Downstream, the projected completion becomes a date you can commit to rather than an optimistic one, because two hours of overrun on the oven no longer ripple straight into the customer promise.

That trade (earlier release and more work in process, bought deliberately, in exchange for a constraint that does not starve) is the whole argument for buffers. Make it consciously, per plant, and revisit it when your variation changes.

Part Four: Direction Precedence

An order can carry several signals about how it should be scheduled at the same time. It can have a pinned constraint, actual dates already logged, planner-placed start pins from a Gantt drag, and a whole-order backward setting that right-aligns everything to the due date. Only one direction can win. The order is fixed:

Two consequences are worth internalizing.

Setting a target start date converts a backward job into an anchored job. That is deliberate. If you want a job to right-align to its due date, do not also pin an operation, because rule 1 will fire on the next run.

Both anchored and backward jobs flip material timing to just in time. Material steps are placed in the window that ends when the material is needed, rather than being pushed as early as possible with everything that consumes them following. That matches the intent of both directions: parts arrive when they are wanted.

Do not confuse the two backward passes. The anchor's backward pass right-aligns only the upstream operations to the pin using a chained deadline. Whole-order backward scheduling right-aligns the entire order to the due date, deriving each step's deadline from where its successor actually landed. Forward versus backward scheduling covers the general distinction.

Part Five: What the Engine Refuses to Do

Three refusals are part of the contract.

It will not move your due date. The customer promise on an order is never rewritten by the scheduler. A projected end date is computed and shown beside it, and the gap between them is your slack or your lateness.

It will not slide the pin to make the plan feasible. If upstream capacity cannot deliver by the pinned date, the constraint still starts when you pinned it and the upstream shows as late. Comparing the last upstream operation's end with the pinned start is the check, and the plan is not silently repaired underneath you.

It will not re-plan work that happened. If the constraint operation carries actual dates, anchoring no longer applies to that job and the remaining downstream operations chain forward from where the actuals ended. Completed work is never moved by a reschedule.

Next Steps

If your anchored plan is not behaving as this post describes, the cause is almost always one of a short list of configuration errors: bottleneck scheduling mistakes maps each symptom to its setting. For how the placement layer under all of this works, read how EDGEBIC allocates hours across shifts. The complete guide to EDGEBIC puts anchoring in context with the rest of the platform.