How a Frozen Routing Snapshot Protects a Running Job

A routing snapshot is an exact copy of the bill of routing a job was scheduled with, saved the first time EDGEBIC by User Solutions schedules that job. On every later reschedule the engine reads the preserved copy rather than the live master routing, so the operation sequence, machine assignments, and step times stay stable for the life of the order even when engineers change the master. The effect is that a change made to a routing halfway through a production run does not quietly re-route an operator's remaining steps, and any change that should apply is a deliberate choice you make per job.

Routings change. Engineers find better methods, swap machines, add an inspection step, correct a cycle time. That is healthy. What is dangerous is when those changes reach through into jobs that are already on the floor and silently rearrange the work an operator has already set up for. The routing snapshot is the mechanism that stops that from happening by default.

Two versions of a routing, on purpose

At any moment a product has two routings that matter:

• The global routing is the live master, what you would see in the routing editor right now. Engineers can change it at any time.
• The preserved routing is the deep copy taken when a specific job was first scheduled. It belongs to that job and does not move when the master changes.

When you schedule a job for the first time, EDGEBIC uses the global routing (a new job has no snapshot yet), then saves an exact copy as that job's snapshot. From then on, every reschedule of that job reads the snapshot. The master can be edited freely, and it will drive the next brand-new job, but it will not reach into a job that already has a plan.

Why the default is to preserve, not update

The reason preservation is the default comes down to the shop floor. Consider a three-step job that is 60 percent complete: the first two steps have actuals, and only the final QC step remains. An engineer then changes that QC step in the master routing, moving it from QC-Bay to Test-Cell and shaving its cycle time.

If the reschedule silently picked up the master change, the remaining QC work would jump to Test-Cell. But the operator's tooling, fixtures, and work instructions were set up for QC-Bay. Re-routing mid-order without warning would invalidate all of that, and the first anyone would learn of it is when the operator finds a job on the wrong machine. So EDGEBIC keeps the snapshot: the QC step stays on QC-Bay, exactly as originally planned, and the job finishes on the routing it started with.

This pairs naturally with the rule that a reschedule preserves completed work. Actuals protect the operations that are already done; the routing snapshot protects the plan for the operations that are not yet done. Together they keep a running job coherent from both ends.

Opting in to a change, per job

Preservation is the default, not a lock. When you decide a routing change should apply to a specific job, you tick Use Global Routing on Reschedule for that job. The next run reads the live master routing, applies the change, and refreshes the snapshot to match. After the run the flag resets, so future reschedules lock to the newly updated routing. The important property is that the pickup is a per-job, deliberate act. Nothing is overwritten behind your back.

There is also a middle path for the common case where you want a validated efficiency gain but not a structural re-route. A hybrid mode keeps each step's work center from the preserved snapshot but adopts significant timing improvements from the master. So a step whose hours dropped from 10 to 4.8 after a method change would pick up the faster number while its machine assignment stays exactly where the operator expects it. Small, noise-level changes are ignored so the snapshot does not drift against every trivial edit.

What the snapshot actually captures

A snapshot is not a shallow date stamp. It records the full routing hierarchy as it existed at scheduling time: every step's sequence number, work-center assignment, setup, run, and queue times, its parallel configuration, and its alternative work centers with their multipliers. It also carries metadata such as when the job was scheduled and the order quantity it was scheduled for.

Because the whole routing is captured, EDGEBIC can do two useful things. First, a later reschedule can reproduce the same plan step for step. Second, a change report can compare the preserved snapshot against today's master routing and show exactly which fields differ, so a planner can see what has changed since the job was scheduled before deciding whether to adopt it. The routing snapshots explainer covers reading that report and the opt-in controls in more detail.

A short worked trace

A new job MO-7001 for a valve is scheduled with a three-step routing: Lathe, Mill, QC. On the first run EDGEBIC uses the global routing, schedules the job, and saves the three steps as the snapshot. The database now holds the job with its preserved routing and the preserve flag set.

Weeks later, with the job partway done, an engineer changes the QC step's machine and cuts its hours. On the next reschedule:

• With the preserve flag left as-is (the default), the job reads its snapshot. QC still runs on the original machine for its original hours. The completed Lathe and Mill steps are preserved; only remaining work re-plans.
• With Use Global Routing on Reschedule ticked, the job reads the master. QC moves to the new machine at the new hours, and the snapshot refreshes so the change is now the job's baseline.

Same job, same engine, two outcomes, and the planner chose which one applied.

Why this is a stability feature, not a limitation

It is tempting to read "uses the old routing" as the system being out of date. It is the opposite: it is the system refusing to let a change you made for future jobs disturb a job that is already running. Audit integrity comes along for free, because you can always see which routing a job was actually scheduled with rather than guessing from whatever the master says today. And schedule stability, the thing operators quietly depend on, is preserved because their instructions and the plan agree.

The routing snapshot sits inside the broader reschedule behavior described in the complete scheduling engine guide, and it is the reason a reschedule that preserves completed work can also promise that the not-yet-done steps stay on their original routing unless you say otherwise.

To see a routing change land on new jobs while a running job holds its original plan, bring your data to a demo.