What Is an Inferred Completion in Rescheduling?

An inferred completion is a routing step that carries no recorded actuals of its own but precedes a step that does, so the scheduler concludes it must have run and backfills its actual dates from the plan. It is the mechanism that keeps a reschedule from trying to place work in the future that the shop floor has already passed. EDGEBIC by User Solutions marks these steps as backfilled so a planner can always see which actuals were typed and which were implied.

How it works

When a reschedule starts, the engine sorts a job's existing operations into their planned order and looks for the last one carrying any actual date at all. That position marks how far shop-floor reality has reached on this job.

Every step at or before that position is expected to have actuals. Any that do not are backfilled: the engine copies the step's scheduled start and end into its actual start and end, and stamps the row so the origin is recorded rather than lost. From that point the step classifies as completed, which means it is preserved exactly as it stands and never re-planned.

The reasoning is dependency logic, not optimism. A routing is a chain. If step three ran, step two must have finished first, because step three could not have started otherwise. Leaving step two blank would tell the engine it is still outstanding, and the engine would dutifully look for capacity to run it after step three had already finished. The resulting plan would be self-contradicting, and the job's resume point would be computed from the wrong place.

Steps after the last logged position are untouched. They have no actuals and nothing implies they ran, so they are re-planned normally from the job's resume point.

A concrete example

A four-step job runs through a cell where the kiosk sits at the last station. The operator at that station logs what passes through it. Nobody logs the first two operations, because there is no terminal there.

The rows read like this. Steps one and two are blank. Step three shows a start on Wednesday morning and an end on Wednesday afternoon. Step four shows a start Wednesday afternoon and an end Thursday morning.

On the next reschedule the engine finds step four as the last row with any actual. Steps one and two sit before it and are blank, so both are backfilled from their planned dates and flagged as inferred. All four steps now classify as completed. There is nothing left to place, so the engine preserves every row verbatim and returns without running a forward pass at all.

The alternative, without inference, would be a plan claiming steps one and two are still to come, scheduled some days after step four finished. Anyone reading that board would stop trusting it immediately.

How EDGEBIC uses it

Inference runs before the classification pass on every reschedule, so it applies to any job where the logged actuals have a gap earlier in the routing. The wider rule it serves is that finished work is never rewritten, which is covered in actuals preservation on reschedule and in why actuals are immutable in EDGEBIC.

Because backfilled dates come from the plan rather than from the floor, they are a placeholder rather than a measurement. A shop that reports on variance should close the gap properly, which is what how to backfill actuals for earlier steps in EDGEBIC walks through. The system marks system-filled entries distinctly, and that badge has its own explanation in the auto-filled actuals badge explained.

Once every step at or before the last logged one is treated as complete, the job's remaining work starts from a computed resume point, which is described in how EDGEBIC preserves completed work on reschedule. For the wider vocabulary, see the manufacturing glossary, and to see reschedules handle real shop-floor data, explore EDGEBIC.