How a Routing Snapshot Settles What You Actually Built

A routing snapshot settles a customer dispute about how a part was built because each job carries a frozen copy of the routing it was scheduled against, so the answer to "what process did you use on this order" is a records lookup rather than a reconstruction. EDGEBIC by User Solutions takes that copy at schedule time and never lets a later master routing edit rewrite it. The business value is not the copy. It is that a claim you can answer in an hour costs a fraction of a claim you answer in two days.

This post covers the dispute outcome. It sits under the EDGEBIC results guide. For how the freeze works, see how a frozen routing snapshot protects a running job.

The Claim You Cannot Answer

A customer calls about an order shipped seven months ago. A part is failing in the field and they want to know whether you deburred it, whether it went through the second inspection, and whether anything about the process changed partway through the order.

You go looking. The routing for that part has been edited three times since: an operation was added, an operation was merged into another, and the mill hours were revised down after a fixture improvement. What you can see today is the current recipe. What you cannot see is which of those three versions was in force when each of the four jobs on that order ran.

So you rebuild the story from a traveler somebody may have kept, an email thread, and the memory of an engineer who has since moved departments. That takes two days, produces a probable answer, and hands the customer something they can reasonably doubt.

What the Snapshot Changes

When a job is scheduled, the routing is copied onto the job. The copy holds the operations, their sequence, the work centers, the hours, and the settings that shaped the plan. From that moment the job runs against its own copy, and edits to the master routing do not reach backward into it.

That single design decision converts the dispute from a reconstruction into a lookup. Three records do the work:

Add the logged actuals and you have both halves of the story: what the job was supposed to do, and what it actually did. The same records are what narrow a quality investigation to a specific machine, operator, and shift. The dates, hours, and work centers on completed operations are preserved exactly as logged, because completed work is never moved by a reschedule.

The Mixed-Floor Reality, Recorded

Any shop that improves its methods runs a mixed floor after every change. Some jobs finish on the old process, some start on the new one, and for a few weeks both are true at once. That is normal manufacturing. What is not normal is being unable to say which job was which.

A worked case. Product A has four jobs on one customer order:

The customer's question, "did our parts go through the extra inspection," splits cleanly: two jobs did, two did not, and you can name the date the change took effect. That is a defensible answer. Compare it with "we believe most of them did," which is what memory produces and which invites the follow-up you do not want.

Why This Is Worth Money

Disputes have three costs, and the snapshot works on all three.

The hours you spend. Two days of an engineer and a quality lead rebuilding a story is not a rounding error, and it recurs. A lookup that takes an hour is roughly a fifteen-fold reduction on that line alone.

The scope you have to concede. Without records, a claim tends to expand to the whole order, because you cannot prove which units differ. With records, the claim narrows to the units genuinely affected. Narrowing a claim from four jobs to two is a direct reduction in whatever you are absorbing.

The relationship. A supplier who answers a process question with dated records reads as controlled. A supplier who answers with an anecdote reads as lucky. That difference shows up at the next sourcing decision, and it is the part you never get invoiced for.

Where the Boundary Sits

A snapshot records the plan, not the physical part. It tells you which operations the job was scheduled against and what was logged as done. It does not measure the part or certify it. Dimensional evidence lives in your quality system, and this record sits beside it rather than replacing it.

It records what the software saw. An operation done a different way and logged as planned looks correct in the record. The snapshot is honest about the plan and about what was logged; it cannot see a decision made at the machine and never entered.

It does not make you compliant with anything. No software does. These are planning records with defined behavior, and they can serve as inputs to a quality system. Deciding what is required and what must be validated is the manufacturer's job. See audit-ready scheduling for that framing.

It only covers jobs that were scheduled in the system. A job run off a whiteboard leaves no snapshot. The record is complete for work the software planned and blind to work it never saw, which is the usual argument for keeping one plan rather than three. See how one source of truth ends spreadsheet sprawl.

The Heritage Case

The lineage behind EDGEBIC includes work where this record was the deliverable, not a byproduct. User Solutions and the RMDB line supported US Navy overhaul planning coordinating more than 26,000 tasks on the USS Nimitz, and regulated manufacturing across the install base where "which version was this built to" is a question asked routinely rather than only after a failure. Shops in that world learned early that a plan you can prove is worth more than a plan that was merely correct. For the change-management side, see change control in manufacturing scheduling.

Want to see what your own jobs would record? Bring a routing and an order history to a demo and we will schedule a job, edit the master routing, and show you what the job still says.