Production Routing Snapshots: Why a Scheduled Job Freezes Its Routing

A production routing snapshot is an exact copy of the routing a job was scheduled with, stored on the job. In EDGEBIC by User Solutions that copy is captured the first time an order is scheduled and read back on every reschedule after it. The master routing stays free to evolve. Orders already on the floor keep running the version their paperwork describes until a planner decides, job by job, to adopt something newer.

This is one of those mechanisms nobody asks for by name and everybody wants the first time an engineering change lands mid-order. This post covers what is captured, when it is written, the three ways it can be read, and where the boundaries of the idea sit.

The Problem It Solves

A routing is not a static document. Engineers improve cycle times, add a deburr operation, reroute a step to a newer machine, and correct a setup estimate that was always optimistic. Those edits are how a shop gets better.

Meanwhile, twenty jobs are open against that routing. Some are queued, some are half done, some have a fixture bolted to a specific machine and a traveler in the operator's hand naming that machine.

A scheduling system with one shared routing has to pick a side. Either it re-plans every open job onto the new routing, which invalidates setups and paperwork that are physically in place, or it refuses engineering edits until the shop is empty, which never happens.

The snapshot dissolves the conflict. Engineering edits the master. Open jobs keep the copy they were planned against. Adoption becomes a per-job decision with a visible trail rather than an invisible side effect. The same principle drives formal change control in scheduling.

What Gets Captured

The copy is not a summary. It holds the full routing structure as it stood at scheduling time.

Alongside the routing itself, the snapshot records the scheduling context: when the job was scheduled, the order quantity used, the scheduling mode, the original due date, and the work center utilization, instance count, and efficiency factor that were in force. That context is what makes a snapshot readable a year later, when the question is not just "what routing did we use" but "what were we assuming when we committed to that date".

Each copy carries a version number, a snapshot date, and a reason, so a job that has been refreshed more than once leaves a legible sequence rather than a single mystery.

When It Is Written

Three moments, and only three.

1. The first scheduling run for the job. A new order has no copy, so the run reads the master routing. What the engine actually used is then copied onto the job.
2. A run where the planner explicitly ticked the option to follow the master routing. The job reads the master, and its copy refreshes to match what was used.
3. A direct edit through the job's own routing view. The planner changed this job's copy on purpose.

Every other reschedule carries the existing copy forward unchanged. That invariant is what makes the mechanism trustworthy: the planner's copy cannot be quietly rewritten by a routine run.

There is one subtlety worth internalizing. A brand new job's first run uses the master routing, because it has no copy yet. So an engineering change made before that first run is picked up automatically. The freeze applies from the first schedule onward, not from order entry.

Three Ways the Copy Is Read

Preserved is the default and the right answer for most live jobs. Global is a deliberate opt-in per job. Hybrid is the interesting middle: it keeps the work center assignments the floor is set up for while adopting timing values that have moved materially, under fixed rules rather than judgment. The rules and the arithmetic behind hybrid are covered in why frozen routings protect in-flight jobs.

Master Routing and Job Copy, Side by Side

The two objects look identical on screen and behave nothing alike, which is the source of most confusion around them.

Read that table once and the behavior that surprises people stops being surprising. Editing the master is a change to the standard. Editing a job's copy is a change to one commitment.

What a Snapshot Does Not Freeze

The word "frozen" invites an assumption worth heading off. Freezing the routing does not freeze the plan.

Dates still move on every reschedule, because dates come from current capacity, current calendars, and the job's resume point. Which alternate work center gets selected is still decided at run time from live availability. Actuals still flow in from the floor. Quantities, priorities, and due dates are all still live.

What is frozen is the definition of the work: which steps exist, in what order, on which stations, with which standard times. Everything about when that work happens stays fully dynamic. A job with a two-month-old routing copy still gets scheduled against today's shift calendar and today's machine load.

What It Looks Like in Practice

A three-step routing for a valve: lathe at 4.0 hours with 0.5 setup, mill at 6.0 hours with 1.0 setup, then a QC bay at 1.0 hours.

The order is scheduled. The copy is written holding those three steps, their machines, their timings, and the context of that run.

Two weeks later the job is 60 percent complete, with the lathe and mill steps carrying actuals. An engineer then edits the master routing: QC moves from the QC bay to a test cell, and its time drops from 1.0 to 0.75 hours.

Reschedule now, with the default preserved mode, and the QC step is planned on the QC bay at 1.0 hours, exactly as originally committed. The operator whose tooling is set up for the QC bay is not surprised on Thursday morning.

If the planner decides the change should apply, they tick the option on that job, run, and the QC step moves to the test cell at 0.75 hours while the copy refreshes to match. Either way the completed lathe and mill steps are preserved verbatim, because completed work never moves on a reschedule regardless of which routing is in play.

Two Things It Is Not

It is not product revision control. The snapshot does not manage which revision of a routing is approved, who signed it, or what changed between revisions. That is engineering's system of record, and EDGEBIC reads it in through the same Excel, CSV, or database import masks it uses for products and work centers. The snapshot answers a narrower question: what was this specific job planned against.

It is not a version history of itself. Each refresh overwrites the previous copy rather than stacking a new version behind it. If you are about to refresh a job onto the master routing and the result might be wrong, export or note the current copy first. The comparison report against the live master is the practical tool here, and it is covered in working with frozen routings.

Where It Touches the Rest of the System

The shop floor terminal. A terminal compares the live routing against the job's copy and raises a banner when the work center, setup time, cycle time, or queue time differ. The operator sees the discrepancy before starting rather than discovering it mid-run.

Actuals. The two mechanisms are complementary. Actuals freeze what happened; the snapshot freezes what was planned. Together they let you answer "did we do what we said, against the routing we said" rather than comparing today's reality to today's standard, which is a comparison that flatters everyone.

The graphical designer. A job's copy can be edited on the same canvas as the master routing, with steps added, retimed, or rerouted for that one order. See the graphical routing designer tour for how the canvas works, and editing a live job's routing for the safe procedure.

When This Matters Most

Four situations where a shop notices the absence of routing snapshots immediately.

• Long-running orders. A job on the floor for three weeks will outlive at least one engineering edit.
• Regulated work. When you have to demonstrate what a job was built to, "the current routing" is not an answer. See audit-ready scheduling.
• Continuous improvement programs. The faster engineering iterates, the more open orders each edit touches.
• Shops where the traveler is printed. Paper on the floor cannot be updated by a database write, so the plan has to match the paper until somebody reprints it deliberately.

If your routings are stable and your jobs clear in a day, you will barely notice the mechanism working. That is the correct outcome. It is insurance, and insurance is boring right up until the week it is not.

Where to Go Next

Working with frozen routings is the operating procedure: where to look, how to compare against the master, and which of the three controls to use. Why frozen routings protect in-flight jobs covers the mechanism and the hybrid merge rules with worked numbers. Routing snapshot mistakes covers the traps.

For routing as a general concept, production routing is the primer. The platform overview is the complete guide to EDGEBIC. Bring a routing you revise often to a demo of EDGEBIC and we will show you what happens to the open orders.