Routing Version Control for Manufacturing: Snapshot vs Live Routing

Routing version control in manufacturing comes down to one question asked at run time: does this job plan against its own frozen copy of the routing, or against the live master? In EDGEBIC by User Solutions the answer defaults to the copy, and every mechanism around that default exists to make the copy trustworthy: it can only be written in three situations, it is cloned before the engine touches it, and it is checked for integrity when it loads.

This post is the mechanism. For the concept, read production routing snapshots. For the procedure, working with frozen routings.

The Decision, Made Once Per Job Per Run

When a scheduling run reaches a job, it resolves the routing source before it plans anything.

The first row explains something people trip over. A brand new order has no copy, so its very first run reads the master. An engineering change made before that first run reaches the job automatically. The freeze applies from the first schedule onward, not from order entry.

The last row is the safety valve. A job with a damaged copy still gets scheduled rather than blocking the run, at the cost of routing drift that only the log reveals. That trade is deliberate: a plant cannot stop scheduling because one record is malformed.

The Clone Rule

Here is the detail that turns a good idea into a reliable one, and it is not obvious.

When the engine reads a job's frozen copy, it does not work on the copy directly. It clones the steps first and schedules the clones.

The reason is alternate work center resolution. During a run the engine may pick an alternate for a step, and it records that pick on the step it is working with. If the engine were working on the copy's own steps, that pick would become part of the saved copy at the end of the run.

The consequence would be subtle and permanent. A reschedule that happened to select an alternate work center once would rewrite the job's saved routing to name that alternate as the primary, forever. The next reschedule would read a copy that no longer described what the planner committed to, and nobody would ever see the moment it changed. Cloning before scheduling closes that path entirely.

The same principle applies wherever a run makes in-flight decisions. The copy is an input, never a scratchpad.

Three Authorized Writes, and Nothing Else

The copy may only be written in three situations.

1. First-time seed. The job had no copy; one is created from the routing the run actually used.
2. Explicit follow-master reschedule. The planner ticked the flag, so the job read the master and the copy refreshes to match.
3. A direct edit through the job's own routing view.

Every other run takes the carry-forward branch: the existing copy is written back unchanged. That branch is the entire guarantee. If a fourth write path existed, the copy would be a suggestion rather than a record.

There is one failure mode worth knowing. If the copy cannot be serialized for some reason during a run, the engine carries the previous copy forward rather than losing it. The job runs correctly against what it read in memory, but the stored copy is not updated, so the next run re-reads the older version. That is the conservative choice and it is why an unexpected routing on a second consecutive run is worth investigating rather than dismissing.

Integrity Checks on Load

When copies are loaded, each is validated. The checks are blunt and useful.

None of these halt the run. Each is recorded, and an empty step list in particular causes the fallback to the master routing described above. That combination is the one to watch for: the job schedules, the dates look plausible, and the routing quietly is not the one the copy was supposed to hold.

Monitoring for those entries is cheap and it is the only signal that separates "the copy was used" from "the copy failed and the master was used instead".

The Hybrid Merge, With Numbers

Hybrid mode is the middle path: keep the job's structure, adopt validated timing improvements. Four rules govern it, applied per step.

Rule 1: work center changes always come from the master. If the master routes a step to a different station than the copy does, the master wins. A rerouting is an engineering decision and the hybrid mode is not the place to second-guess it.

Rule 2: run time is adopted when the change is material. The difference must exceed 0.1 hours and be either a reduction greater than 10 percent, or an increase under 5 percent.

Rule 3: setup time uses a tighter band. The difference must exceed 0.05 hours and be either a reduction greater than 5 percent, or an increase under 10 percent.

Rule 4: sequence numbers update when the master has restructured the routing.

Steps that exist in the master but not in the copy are appended and tagged as new, then the whole list is re-sorted by sequence.

Work two steps through it.

A press operation sits at 10.0 hours in the copy. Engineers halved the cycle and the master now says 4.8 hours, same station, same 0.5 hour setup.

Result: Press-2 at 4.8 hours with a 0.5 hour setup. The routing is preserved, the validated gain is taken.

Now a second step where somebody nudged the run time from 2.0 to 2.08 hours, a 4 percent increase.

That is under the 5 percent small-increase cap, so it is adopted as a minor correction. The reasoning is that refusing every tiny increase would let a job's copy drift steadily below reality until its dates were systematically optimistic. Had the increase been 6 percent, it would have been rejected as too large to absorb without review.

The band is doing real work in both directions: it keeps improvements flowing and it keeps unreviewed inflation out.

What the Copy Gives You for Audit

Three artifacts, and together they answer most reconstruction questions without asking anyone to remember anything.

The copy itself. Steps, work centers, setup and run times, queue times, yields, parallel configuration, and alternates with their multipliers and priorities, exactly as they stood when the job was scheduled. Alongside them, the scheduling context: the date and time of scheduling, the order quantity, the mode, the original due date, and the work center utilization, instance count, and efficiency in force.

The reschedule counter. Each copy accumulates a count and a timestamped preservation context, so a job rescheduled four times shows four, with the moment of the most recent one. That is how you tell a copy that has been carried forward untouched from one that has been refreshed.

The comparison report. Run the copy against the current master and get a field-level difference list per step. This is the artifact for the "what changed since we committed" question, and it is the one to run before any refresh.

One limitation to plan around: there is no automatic version history behind the copy. Each refresh overwrites the previous state. If a refresh might be wrong, capture the current state first. The comparison report before the refresh is usually enough.

The Trap Worth Knowing

A subtle one, and it generalizes.

A job's copy is stored as a self-contained record with no round trip through the master routing tables. That is what makes it independent, and it also means any field left at its default when the copy is written stays at that default permanently.

The documented instance: a step added to a job's copy through the graphical designer could be saved without its end product association, because the canvas conversion only filled that field for steps loaded from the master. The engine filters a job's steps by end product, so the new step was silently dropped from the plan. The symptom was "my new step did not schedule", which does not point at anything obvious.

It is fixed at both ends now: the field is stamped when the copy is saved, and existing copies are healed when they load. But the lesson stands for anyone extending the model. A per-job copy has no database to fall back on, so whatever the save path does not fill, nothing ever will.

Practical consequence for planners: after adding a step to a job's copy in the designer, reschedule and confirm the step appears in the plan. Five seconds of verification against a class of failure that is otherwise invisible. Steps scheduled out of sequence covers the neighboring symptoms.

Why This Shape

Every design choice here points the same direction: make the copy boring and reliable rather than clever.

Three write paths instead of an open door. Clones instead of in-place work. A fallback that keeps scheduling instead of failing. Fixed hybrid thresholds instead of per-job tuning. Integrity checks that log rather than halt.

The result is a record a planner can trust without inspecting it, which is the only kind of routing version control that survives contact with a busy shop. The alternative, a system where the saved routing might have been rewritten by any run, is one nobody checks and everybody eventually distrusts. The same reasoning underpins completed work never moving on a reschedule: a guarantee you have to verify is not a guarantee.

Where to Go Next

Production routing snapshots is the concept. Working with frozen routings is the procedure. Routing snapshot mistakes covers the ways this gets misused.

For the editing workflow on one live job, see editing a live job's routing, and for routing structure generally, production routing. The platform overview is the complete guide to EDGEBIC. Bring a revised routing and an open order to a demo of EDGEBIC and we will run the comparison live.