You prove it by producing an auditable record that ties three things together for that specific serial number: the work executed, the instruction revision released at that time, and evidence that operators used that revision during execution.
In practice, that usually means a traceable chain such as serial number to work order or traveler, then to operation record, then to the controlled instruction revision, with time stamps, status history, and user or system actions preserved. If your systems cannot show that linkage, you may be able to infer it, but that is weaker evidence and may not satisfy a skeptical auditor.
What evidence is typically credible
-
A device history record, traveler, or MES execution record that includes the serial number and operation completion details.
-
A document control or PLM record showing the exact instruction revision that was effective and released for use at the time of execution.
-
A system-generated link between the execution record and that exact revision, not just the current document number.
-
Time stamps, electronic signatures where applicable, and an audit trail showing who viewed, launched, printed, acknowledged, or completed the instruction-controlled step.
-
If paper was used, the controlled printed copy number, issuance log, and returned traveler or packet showing the revision identifier actually issued to the floor.
The strongest case is when the revision is captured automatically at the moment the operation is started or completed. The weakest case is when teams try to reconstruct the answer later from current documents, memory, or informal file shares.
What usually does not count as strong proof
-
The current revision in PLM or QMS without evidence that it was the one used for that serial number.
-
A training record showing an operator was trained on a revision, without execution linkage to the specific unit.
-
A shared drive PDF with modified dates but no controlled release record.
-
A paper packet that lacks revision markings, issuance control, or reconciliation.
-
An ERP work order that references only a document number and not the specific revision.
Those artifacts can support the story, but by themselves they often leave gaps around timing, release status, and actual use at the point of work.
What your process needs to support
If this proof matters regularly, the process should capture revision usage as part of execution, not as a separate after-the-fact reporting exercise. Common controls include:
-
Revision-controlled work instructions released through formal change control.
-
Effective dating, supersession history, and retained prior revisions.
-
Automatic binding of the active revision to the work order, operation, lot, or serial number at dispatch or start.
-
Blocking use of obsolete revisions, or at minimum flagging exceptions with approval records.
-
Controlled print workflows if paper remains in use.
-
Retention policies that preserve historical records for the required lifecycle.
Whether you can do this reliably depends on system configuration, data discipline, and governance. Many organizations own the right software modules but never configure the revision linkage all the way through execution.
Brownfield reality
In mixed environments, the answer is often partial. PLM may own released revisions, MES may record execution, ERP may hold work orders, and some areas may still run paper travelers. In that setup, proving the exact revision used depends on integration quality and procedural rigor. If the handoff between systems drops the revision identifier, or if operators print uncontrolled copies, the evidence chain breaks.
That is why full replacement is often not the practical answer. Replacing MES, ERP, PLM, and QMS stacks to solve this single traceability problem usually runs into validation burden, downtime risk, qualification impacts, integration complexity, and long asset lifecycles. Most plants get better results by tightening document governance, improving system handoffs, and capturing revision references at the point of execution inside the systems they already run.
If you cannot prove it today
Say that plainly and define the gap. A defensible response is better than overstating capability. You can usually classify the current state like this:
-
Direct proof: the serial number record explicitly references the exact revision used.
-
Indirect reconstruction: you can infer the likely revision from release dates, work order dates, and controlled issuance records.
-
Insufficient evidence: the process does not preserve enough information to make a reliable determination.
If you are in the second or third category, the corrective action is procedural and technical: bind revision identifiers to execution records, validate the data flow, control printing, and audit the process periodically to confirm the link still holds after changes.