If you're a defense supplier, you've probably heard about DoD Instruction 5000.97. Released in December 2023, it formalizes digital engineering as a core requirement across the defense acquisition lifecycle. New programs must incorporate digital engineering. Existing programs should adopt it to the maximum extent practical.
Most coverage of the directive focuses on model-based systems engineering, digital twins, and enterprise data strategy. Those are important. But there's a practical implication that gets far less attention: what 5000.97 means for the work instructions your technicians follow every day on the shop floor.
The directive doesn't just call for digital models at the engineering level. It mandates that digital artifacts, including production instructions, replace documents as the primary means of communicating system information. For defense manufacturing suppliers, that changes the compliance conversation entirely.
This article breaks down what the directive actually requires, what it means for your manufacturing operations, and where to start.
Read the full directive: DoDI 5000.97 (PDF) | DoD Summary Document (PDF)
The directive establishes three things defense suppliers need to understand immediately.
First, the mandate itself. Programs initiated after December 2023 must incorporate digital engineering unless the program's decision authority grants an exception. Programs initiated before that date should incorporate digital engineering when practical, beneficial, and affordable. The language is carefully graduated, but the direction is clear: digital engineering is the expectation, not the exception.
Second, the shift in how engineering information is communicated. The directive states that the primary means of communicating system information moves from documents to digital models and their underlying data. Digital models become central to how engineering activities are performed. This isn't a preference. It's policy.
Third, the scope. The directive's digital engineering framework spans requirements, architecture, design, development, testing, production, training, and sustainment. It covers the full acquisition lifecycle, which means it reaches all the way to the manufacturing floor and into field service. If your organization touches a defense program at any point in that lifecycle, 5000.97 applies to how you communicate engineering information.
The timeline pressure is real. Defense acquisition programs are being evaluated against these requirements in active source selections and program reviews right now. Suppliers who can demonstrate a compliant digital engineering posture have a competitive advantage. Those who can't are carrying a risk their prime contractors will eventually need to address.
Section 3.2 of the directive defines digital artifacts as products and views that can be dynamically generated from digital models. It then lists specific examples, and several of them map directly to manufacturing operations.
Production and machining instructions are explicitly named as digital artifacts. The directive envisions these as outputs generated from digital models, not standalone documents created separately from the engineering source data. For a defense supplier, this means the work instructions guiding assembly, machining, and inspection should trace back to the digital model that defined the product. A PDF attached to a work order, manually updated when the design changes, doesn't meet that standard.
Bills of material are also listed as digital artifacts that should be linked to digital models. If your BOM lives in a PLM system but your work instructions reference a separate, static version of that BOM, you have a traceability gap. The directive requires that these artifacts connect to the same authoritative source of truth.
Design specifications and technical drawings are positioned as views generated from models, not as freestanding documents. This aligns with the broader model-based engineering movement, but it also has a downstream implication: the instructions that tell a technician how to build what the specification defines should draw from the same model, not from a derivative document that may or may not reflect the current revision.
The critical point across all of these artifact types is traceability. The directive requires that digital models and their data be traceable from operational capabilities through requirements, design, production, test, training, and sustainment. That traceability chain doesn't stop at the engineering department. It extends through to the work instruction on the shop floor and the execution data captured when the work is performed.
This is where the directive turns from a technology discussion into an architecture decision. It's not enough to digitize your documents. The artifacts themselves must be connected to the engineering data that authorizes them, and that connection must be maintained as designs evolve.
The traceability mandate in 5000.97 maps to a structural problem that most defense manufacturers already know they have, even if they haven't framed it this way.
At Canvas Envision, we describe this as the first mile and last mile of the digital thread.
The first mile is capturing expert knowledge and bringing it into the digital thread in the first place. In most defense manufacturing organizations, critical knowledge lives in places the digital thread has never reached: in the heads of experienced workers approaching retirement, in legacy technical orders and paper procedures accumulated over decades, in tribal knowledge passed informally from one technician to the next. Getting that knowledge formalized, structured, and into the digital thread is the foundational challenge, and it's one that rarely gets the time it deserves. Production needed to start yesterday. Products need to ship. Revenue needs to come in. The people who carry the knowledge are under constant pressure, and the task of capturing what they know into structured instructions gets deferred until it's too late.
That's the first-mile problem: not just connecting engineering data to instructions, but capturing the knowledge that makes those instructions useful and converting it into interactive, governed content. Once that knowledge is in the digital thread, it can be connected to engineering CAD data, creating model-based work instructions that meet the standard the directive requires. But the capture has to happen first.
The last mile is the connection between the work instruction and the point of execution. When a technician performs an assembly, an inspection, or a maintenance procedure, the instruction they follow must be traceable back to the engineering source data that authorized it. And the data captured during execution, such as inspection results, as-built confirmations, completion records, and non-conformance reports, must feed back into the digital thread for compliance, quality, and continuous improvement.
Most defense suppliers have invested in the middle of this chain. They have PLM systems managing engineering data. They may have model-based engineering practices in place. But the connection between the PLM system and the shop floor instruction is still manual for the majority of organizations. Someone exports a PDF or a drawing package, attaches it to a traveler or a work order, and the instruction becomes a static snapshot of what the engineering data looked like at the time of export.
That manual handoff is where traceability breaks. The resulting instruction isn't connected to the work being performed. It sits on a different tab, a different screen, or a different clipboard. It's a reference document the technician consults, not the surface through which the work gets done and data flows back. Under 5000.97, that disconnection is now a compliance risk, not just an efficiency problem.
The directive's own language makes this explicit. It calls for a digital engineering capability that connects the phases of the acquisition lifecycle, allowing feedback and flow of information across acquisition activities and processes. It describes the digital thread as a framework that should support the feedback loop over the lifecycle. The requirement isn't just top-down delivery of engineering data. It's a closed loop where execution data flows back into the authoritative source of truth.
For defense suppliers evaluating their 5000.97 posture, the question isn't whether they have digital tools. It's whether their instruction chain, from engineering model to shop floor execution to captured feedback, is connected and traceable.
When defense suppliers hear "model-based" in the context of 5000.97, the immediate association is usually model-based systems engineering: SysML diagrams, requirements models, system architectures. That's one important layer of what the directive addresses. But 5000.97 also applies to the manufacturing execution layer, specifically the instructions that tell a technician how to build, inspect, or maintain the product.
Model-based work instructions are fundamentally different from digitized documents. The distinction matters for compliance.
A model-based work instruction is authored from the engineering data itself. The 3D model that defined the part geometry, the assembly relationships, and the component metadata is the same model used to create the instruction. The author doesn't recreate an illustration from scratch or paste a screenshot from the CAD system. They work directly with the engineering model, its geometry, its metadata, and its revision history.
A model-based work instruction is delivered as an interactive digital artifact. The technician can rotate a 3D view, isolate components, step through an assembly sequence, and see exactly what goes where in spatial context. This isn't a PDF with a 3D rendering on the first page. It's a procedure where the engineering model is the medium of instruction, not a static image derived from it.
A model-based work instruction is connected to the digital thread. When engineering issues a change order and the model updates, the delta flows into the instruction for review, restructuring, and visual updates, then is released to the production floor. That governed change management process is what makes the instruction a living digital artifact rather than a static document that may or may not reflect the current design.
A model-based work instruction captures execution data back into the digital thread. The directive calls for the digital thread to support a feedback loop over the lifecycle, with information flowing back into the authoritative source of truth. In practice, that means the data flow can't be one-way. Inspection results, completion confirmations, operator feedback on procedure clarity, and non-conformance documentation all need to feed back into the system of record. This is what transforms a one-way delivery mechanism into an interactive, bidirectional system that meets 5000.97's digital thread requirements.
Consider a concrete scenario: a technician at a mid-tier A&D supplier is assembling an avionics subassembly for a prime contractor program. The engineering team releases a revision that changes a connector routing. If that update is missed, misunderstood, or reaches the floor after the technician has already started building to the old revision, the result is a routing error. In defense manufacturing, that error isn't just a rework event. It's a potential safety-of-flight issue that could surface months later during depot maintenance. The stakes are real.
Under the old workflow, someone exports a new PDF, emails it to the floor supervisor, and hopes the technician gets the updated version before starting the next unit, hopes they read it, hopes they notice what changed, and hopes they comprehend the intent from a static document. That's a lot of wishful thinking. Under a model-based workflow, the revision flows from PLM into the work instruction for review. The author sees exactly what changed, quickly incorporates the changes into the instruction, adjusts as needed, and publishes the updated revision. The technician opens an interactive instruction where the new routing is visible in 3D context, steps through the updated sequence, and confirms completion. That confirmation feeds back into the digital thread as an auditable execution record. The traceability chain the directive requires is intact from engineering intent through shop floor execution.
Canvas Envision is built on this architecture. Envision Creator captures expert knowledge from whatever form it exists in today, whether that's 3D CAD models, legacy PDFs, training videos, or direct input from subject matter experts, and structures it into interactive work instructions. Evie accelerates that capture, restructuring the source material in minutes. The author then incorporates the result, adjusts it against their own expertise, and publishes, which keeps a qualified person accountable for what reaches the floor. Envision Connector then links those instructions to the engineering source data in PLM systems, so the instruction becomes a model-based, governed artifact that stays current as designs evolve. And Envision Operator delivers those interactive instructions to technicians on whatever device fits the work environment and captures execution data from named users, creating the traceability and feedback loop the directive requires.
The directive doesn't call for better documents. It calls for digital models to replace documents as the primary means of communicating system information. That's what Canvas Envision does: replace documents with connected, interactive instructional experiences that extend the digital thread to the shop floor and capture data back from execution.
If you're a defense manufacturing supplier reading this directive and wondering where to begin, here's a practical starting point.
Map your current instruction chain. Trace how engineering data reaches the shop floor today. Identify every point where information moves from a governed system (PLM, CAD, MES) into an ungoverned format (PDF, email, printed traveler, screenshots, digital photos, videos on a shared drive). Each of those handoff points is a traceability gap under 5000.97. You likely already know where they are. The directive just turned them into compliance risks.
Prioritize new programs. The mandate is strongest for programs initiated after December 2023. If your organization is bidding on or executing new defense programs, those are where your digital engineering posture will be evaluated first. Existing programs have more flexibility, but the direction is clear.
Capture what you have now. The first-mile problem isn't only about connecting systems. It's about getting critical knowledge into a structured, digital format before it walks out the door. If your experienced technicians' know-how lives in their heads, in paper notebooks, or in legacy technical orders that haven't been updated in years, that knowledge is at risk. Start by converting existing documentation and capturing expert procedures into interactive instructions, even before you connect to PLM. Getting the knowledge into the digital thread is the foundation everything else builds on.
Connect your work instruction authoring to PLM. Once knowledge is captured in structured instructions, the next architectural step is linking those instructions to your product lifecycle management system. When the engineering model becomes the source for the instruction and the instruction stays linked through revision cycles, you satisfy the traceability requirement at the root. This is what PLM integration and 3D model-based work instructions enable, and it's why the directive explicitly calls out PLM as a digital engineering methodology.
Plan for bidirectional data flow. The directive calls for feedback loops and for digital models to be updated with real-world data throughout the system lifecycle. In practice, that means your instruction system shouldn't just deliver procedures to the workforce. It should also collect completion records, inspection results, and operator feedback that flows back into the digital thread. If your current system is one-way, that's a gap worth closing.
Assess your readiness. Before you can close the gaps, you need to know where they are. A structured readiness assessment, covering your instruction authoring workflow, PLM integration status, shop floor delivery method, and data capture capabilities, gives you a clear picture of your 5000.97 posture and a prioritized action plan.
DoD 5000.97 is a compliance requirement, but it's also a forcing function for an architectural upgrade that pays dividends beyond the regulatory checkbox.
Defense suppliers who connect their engineering data to their shop floor instructions through a governed, traceable, interactive and bidirectional platform don't just satisfy the directive. They avoid a common architectural mistake: embedding work instructions directly in CAD files. That approach may look like it solves traceability, but it means every instruction change, even a procedural clarification or a tooling update, requires a formal engineering change order because the instruction lives inside the engineering data. Those ECOs are expensive, slow, and consume engineering resources for non-engineering changes. The better architecture decouples the instruction from the CAD data while keeping it connected for change impact analysis and controlled updates. Instructions can be revised independently without triggering an ECO, but when the engineering model does change, the impact flows into the instruction for review. That architecture also accelerates technician onboarding by replacing tribal knowledge with structured, visual guidance, and creates an auditable execution record that satisfies not just 5000.97, but AS9100, FAA, and other regulatory frameworks their defense programs already operate under.
The organizations that build this architecture now will carry a competitive advantage into every prime contractor evaluation and source selection that follows. The directive made the requirement explicit. The opportunity is to use it as the catalyst for a capability that compounds.
The standard calls for digital artifacts that are connected to engineering source data, model-based, interactive, and traceable across the system lifecycle. Canvas Envision is built to deliver exactly that. If your organization is evaluating its 5000.97 posture, explore how the Envision Connector integrates with your PLM systems.
Garth Coleman is CEO of Canvas Envision, where he is changing how manufacturers capture, share, and execute the knowledge their best people carry. He brings nearly three decades in enterprise software spanning CAD, Product Lifecycle Management (PLM), and 3D communication, including senior leadership at Dassault Systèmes.
Book a demo with your own CAD data. Most teams are authoring in minutes.
