Which Routing Actually Built This Lot?

In device manufacturing, "which routing actually built this lot" has to be answerable from records rather than memory. EDGEBIC by User Solutions answers it by copying the entire routing onto each job the first time that job is scheduled, then reading that copy on every reschedule afterward. The master routing stays free to improve. The job keeps the version it was actually committed to.

A scope note before anything else, because it matters more here than in any other industry on this site. What follows describes what the scheduling software records and how those records behave. It does not describe a certification, a validation package, or conformance with any regulation or standard. EDGEBIC records planning facts. Your quality system decides what those facts mean and which controls apply to them.

The Pain: Engineering Change Never Waits for an Empty Shop

Device routings change constantly, and for good reasons. A supplier qualification closes, so a step moves in-house. A process validation finishes and a cure time drops. A CAPA adds a verification operation between two existing ones. An inspection method moves from a manual bay to a coordinate measuring machine.

Meanwhile the shop is full. Twenty or forty orders are open against that routing. Some have not been released. Some are queued. Some have a fixture bolted to a named machine, a program loaded, and a traveler in an operator's hand that says exactly where the part goes next.

A scheduling system with one shared routing has to pick a side, and both sides are bad. Re-plan every open job onto the new routing and you invalidate setups and paperwork that physically exist on the floor. Refuse the engineering edit until the shop is clear and you never make the change, because the shop is never clear.

The routing snapshot removes the choice. Engineering edits the master. Open jobs keep the copy they were planned against. Adoption becomes a per-job decision with a date on it. The mechanism itself is covered in depth in how routing snapshots work; this post is about what it means when the parts are implants, catheters, and instrument sets.

What Gets Frozen, Exactly

The copy is not a summary line or a revision number. It is the routing structure as it stood at the moment of scheduling.

Alongside the routing, the copy records the scheduling context: the capture timestamp, the order quantity used, the scheduling mode, the original due date, and the work center utilization, instance count, and efficiency factor in force at the time.

That context is what makes a copy readable a year later. The useful question is rarely "what routing did we use". It is "what were we assuming about that machine when we committed to that date", and the answer is in the record.

Each copy also carries a version number, a capture date, and a reason string, so a job refreshed more than once leaves a legible sequence instead of one undated mystery.

Worked Example: An Inspection Step Moves Mid-Order

Take job MO-7001 for a valve body, three operations.

The job is scheduled. The copy is written: three steps, QC bay at 1.0 hour, plus the context above.

The job reaches roughly 60 percent complete. S10 and S20 have actual start and end dates logged. An engineer then revises the master routing: S30 moves from the QC bay to a test cell and drops from 1.0 hour to 0.75.

The next scheduling run reads the job's own copy, not the master. It classifies S10 and S20 as complete and leaves them exactly as they were logged. It reschedules S30 on the QC bay for 1.0 hour, which is what the paperwork on the floor says.

That behavior is the whole point. The operator has a fixture and an instruction set for the QC bay. Silently rerouting a half-built lot to a test cell would invalidate both without anyone approving it. The reasoning behind protecting in-flight jobs this way applies to every industry; in device work it is the difference between a controlled change and an undocumented one.

If the planner decides the change should apply, they tick the option to use the master routing on the next reschedule for that job. The run then reads the master, S30 becomes the test cell at 0.75 hour, and the copy refreshes to match. One job, one decision, one dated record.

A Middle Setting: Adopt Timing, Keep the Routing

There is a third option between "keep everything" and "take everything", and in device work it is often the right one.

A hybrid mode merges the job's copy with the current master routing under four rules. If the work center on a step changed, the master wins, because a routing change is a structural decision. If run hours differ by more than a tenth of an hour and the change is either a reduction of more than 10 percent or an increase of less than 5 percent, the master's hours are adopted. Setup time follows a similar band. And sequence numbers update if the master restructured the routing.

The point is which changes propagate. A validated cycle-time reduction from 10.0 hours to 4.8 is a 52 percent improvement and is adopted, because the machine really is faster and the plan should say so. A tentative correction from 2.0 hours to 2.08, a 4 percent increase, is inside the minor-update band and is also adopted, so the copy does not drift against small legitimate fixes. An increase of 6 percent is above the cap and is rejected, because a material slowdown on a live job deserves a decision rather than an automatic adoption.

Steps that exist in the master but not in the job's copy are appended and tagged as new, so a deburr operation added between two existing ones is visible rather than silently absent.

Reading the Difference Later

Two records answer the two questions an audit or an investigation usually asks.

The first is the job's copy itself, visible on the job's own routing view. It lists the steps, the work centers, the hours, the sequence, and the alternates as scheduled, plus the capture metadata.

The second is the routing comparison report. It walks the job's copy against today's master routing and prints, per step, exactly which fields differ. If a job ran a step on a machine that is no longer in the standard, the report names the field and both values rather than leaving someone to eyeball two printouts side by side.

The copy also accumulates a reschedule count. A job rescheduled four times carries that number, with the timestamp of the most recent preservation. Frequent reschedules on a single lot are worth a look on their own; the count makes them visible instead of invisible.

Where the Boundaries Are

Being straight about the limits is more useful than a longer feature list.

The job copy holds one current version. Refreshing a job onto the master routing overwrites the previous copy rather than versioning it. If you need the prior state, export or print it before you refresh. The comparison report exists precisely so you can capture that difference deliberately before making it.

An empty or corrupt copy falls back to the master routing rather than halting the run, and logs a warning while doing so. That is a safety default: the job still schedules. It also means the warning matters, because a silent fallback is a routing change nobody chose. The schedule diagnostics surface those warnings so they are read rather than buried.

The scheduling record is not a device history record, an electronic signature system, or a document control system. It records what was planned, when, and against what. Everything downstream of that belongs to your quality system.

Where It Sits Against the Rest of the Stack

Most device manufacturers already run revision control in an ERP or PLM system. That system governs the product standard: which revision is current, who approved it, what changed. The routing copy does not replace it and does not try to.

The two answer different questions. Revision control tells you the approved standard. The job copy tells you what a specific order was actually planned against, captured automatically at schedule time with the scheduling context attached. In practice you want both, and EDGEBIC pulls the standard in through Excel, CSV, and database import masks so neither system has to own the other.

For the broader picture of routing structure, sequencing, and alternates, start with the bill of routing guide. For scheduling practice specific to device manufacturing, see the medical device scheduling overview and the medical device manufacturing software page. The same per-job record does duty in food, where the production record behind every batch is what a recall inquiry actually asks for.

What to Do With This

If you make devices and your scheduling system shares one live routing across every open order, you have an exposure that has nothing to do with software features. It is that nobody can state, from records, which routing a finished lot was actually built against.

Three questions worth asking about whatever system you run today:

1. When an engineer edits a routing at 10 a.m., what happens to the 40 jobs already scheduled against it?
2. If a lot shipped six months ago, can you print the routing that job was planned with, or only the routing that exists now?
3. When someone adopts a routing change on an in-flight job, is that action dated and attributable?

If any answer is uncomfortable, the fix is structural rather than procedural. Bring an export of your routings and open orders to a working session and we will schedule them: see EDGEBIC or the rest of the industry applications in this series.