Digital systems determine which version of instructions to show by matching the execution context to approved version-control rules. In practice, that context usually includes the work order, part number and revision, routing operation, serial or lot number, effectivity date, configuration, site, customer or program, and sometimes nonconformance or rework status. The system should not be guessing; it should be resolving a controlled instruction version from governed data.
What the system normally uses
The exact logic varies by plant and system architecture, but the most common inputs are:
- Work order or job order: ties the operator session to a specific build, repair, or inspection activity.
- Part number and revision: links the job to the applicable design or process baseline.
- Routing and operation: determines which instruction applies at that manufacturing or maintenance step.
- Serial, lot, or unit configuration: supports effectivity when different units require different instructions.
- Document status: prevents draft, obsolete, or unapproved content from being used in production.
- Site, customer, or program rules: handles cases where similar work has different contractual, quality, or regulatory requirements.
Where the version decision usually comes from
In a mature environment, the MES or execution system does not own all of this logic by itself. It commonly receives or references data from PLM, ERP, QMS, document control, maintenance systems, or engineering change systems. The instruction displayed to the operator is the result of those relationships being correctly modeled and maintained.
For example, PLM may define the released engineering revision, ERP may release the work order, MES may control the routing step, and QMS may control deviations, nonconformances, or rework instructions. If those systems disagree, the digital instruction system needs a defined precedence rule or a stop condition. Otherwise, it can present a clean user interface while still showing the wrong content.
Effectivity is the hard part
Version control is not just “latest approved revision.” In regulated manufacturing and MRO, the correct instruction may depend on serial number, lot, aircraft tail, modification status, customer flowdown, repair disposition, or the date the work was released. Showing the newest instruction is not always correct for work already in process.
This is why effectivity rules matter. They define when a version becomes applicable and to which units, orders, operations, or configurations. Poor effectivity data is one of the common reasons digital work instruction programs fail in brownfield environments.
Common failure modes
- Uncontrolled copies: PDF files or local work aids are uploaded without a reliable approval state.
- Weak master data: part revisions, operation codes, or routing links are incomplete or inconsistent.
- Broken integrations: MES, ERP, PLM, or QMS updates arrive late, fail silently, or are mapped incorrectly.
- Ambiguous change timing: engineering changes are released without clear production effectivity.
- Rework exceptions: nonstandard instructions are handled outside the controlled execution record.
- Legacy coexistence: older systems remain authoritative for some data, while new systems assume they are not.
What controls are usually needed
A credible implementation normally requires approved source documents, controlled revision states, defined effectivity logic, validated integrations, role-based access, audit trails, and change control. It also needs a clear rule for what happens when the system cannot determine the correct version. In regulated operations, that should usually trigger a hold, escalation, or manual review rather than allowing the operator to choose from multiple plausible versions.
Full replacement of legacy MES, ERP, PLM, or QMS platforms is often unrealistic in aerospace-grade and similarly regulated environments. The qualification burden, validation cost, downtime risk, integration complexity, traceability obligations, and long equipment lifecycles usually make coexistence the practical path. That means the version-selection logic must be designed around the actual system of record landscape, not an ideal architecture.
The practical test is simple: for any completed unit or order, the organization should be able to show which instruction version was available, why it was applicable, who approved it, when it changed, and what record proves it was used. If the digital system cannot support that trace, it may improve presentation, but it is not yet reliable version governance.