Systems Engineering in the Model-Based Era: Standards, Evidence, and What Actually Works

Almost every consequential product built today — a hospital's imaging suite, a grid-scale battery installation, a driver-assistance stack, a satellite constellation, a national payments rail — is an assembly of subsystems supplied by different organisations, governed by different standards, and changing on different clocks. The dominant source of failure in such products is rarely a badly designed component. It is the space between components: interfaces that were assumed rather than specified, requirements that drifted, operating assumptions that were never tested against how humans actually behave.

Systems engineering is the discipline built to manage exactly that space. It is also a discipline in the middle of a genuine methodological transition, from documents to models, and from models to connected digital environments. That transition is now embedded in international standards and, in some sectors, in procurement policy — which means it is no longer optional for engineers who work on complex programmes.

This article explains the foundations that have remained stable for decades, describes what has changed since 2022, examines what the peer-reviewed evidence does and does not support, and sets out a practical adoption path. It is written for engineers and engineering leaders who need to make defensible decisions about method, tooling, and investment.

---

Executive summary

• Systems engineering is defined internationally by ISO/IEC/IEEE 15288, whose second edition (May 2023) added new material on concept and system definition and a new annex addressing model-based systems engineering (ISO/IEC/IEEE, 2023).
• The INCOSE Systems Engineering Handbook, 5th edition (2023) is the practitioner companion to that standard and the basis of INCOSE certification (Walden et al., 2023).
• SysML v2 — together with KerML 1.0 and a standard modelling API — reached final adoption at the Object Management Group in 2025, the most significant change to systems modelling notation in roughly fifteen years (OMG, 2025).
• Empirical support for systems engineering as a practice is reasonably strong but correlational; support for MBSE specifically is weak. A systematic review found that roughly two-thirds of claimed MBSE benefits rested on perceived rather than measured evidence (Henderson & Salado, 2021).
• Policy is moving faster than evidence. DoD Instruction 5000.97 (effective 21 December 2023) directs new US defence acquisition programmes to incorporate digital engineering unless granted an exception (US Department of Defense, 2023).
• Outcomes in the most heavily engineered sector remain poor: the US GAO's 24th annual weapon systems assessment (2 July 2026) reported an average time to deliver capability of over 12 years across the portfolio it reviews (GAO, 2026).
• Generative AI is being tested as a modelling assistant. Published benchmarks show current large language models perform poorly at generating complete, valid system models unaided (Jin et al., 2025).
• The practical conclusion for most organisations: adopt model-based methods incrementally, on a defined scope, with measurement designed in from the start — not as an enterprise-wide tooling programme.

---

The problem systems engineering was created to solve

Systems engineering emerged from mid-twentieth-century aerospace, defence, and telecommunications programmes in which no single engineer could hold the whole design in mind. Its core proposition is unglamorous: define the problem before the solution, decompose the solution deliberately, control the interfaces, and verify at every level of decomposition against what was actually agreed.

Three ideas do most of the work.

Requirements as a chain of agreement. Stakeholder needs are transformed into stakeholder requirements, then into system requirements, then allocated to elements. Each transformation is a place where meaning can be lost, which is why traceability — the ability to answer "why does this exist, and what verifies it?" — is treated as a first-class engineering artefact rather than paperwork.

Architecture as the management of interfaces. Architecture is not a picture of boxes. Under ISO/IEC/IEEE 42010:2022, an architecture description is a structured artefact organised around stakeholder concerns and viewpoints; the second edition generalised its subject from "system of interest" to "entity of interest" so that it applies to enterprises and product lines as well as systems (ISO/IEC/IEEE, 2022).

Verification and validation as distinct questions. Verification asks whether the system was built to specification. Validation asks whether the specification was the right one. Programmes that conflate the two can pass every test and still deliver something unusable.

These ideas are conventionally drawn as a "V" — decomposition down the left, integration and test up the right. The V is a useful teaching device and a poor description of practice. ISO/IEC/IEEE 15288 is explicit that its processes are applied iteratively, concurrently, and recursively, and prescribes no particular life-cycle model (ISO/IEC/IEEE, 2023). Treating the V as a mandated sequence is one of the most common misreadings in the field.

---

The standards spine

Practitioners are frequently confused about which standard governs what. The table below is an original summary of the documents most often encountered together on complex programmes.

Callout — a distinction worth keeping straight A standard tells you what properties your process or artefact must have. A handbook tells you how competent practitioners usually achieve them. A language gives you a notation. A methodology tells you the order in which to use it. Buying a tool supplies none of the four.

---

From documents to models

Document-based systems engineering stores authoritative information in prose: specifications, interface control documents, trade studies. Its weakness is not that documents are unclear — good ones are very clear — but that consistency between them must be maintained by humans. On a programme with thousands of requirements and dozens of suppliers, that maintenance cost grows faster than the programme's ability to pay it.

Model-based systems engineering (MBSE) moves the authoritative source into a formal, machine-readable model from which documents are generated as views. The claimed advantages follow directly: a change to an interface propagates to every view that depends on it; consistency can be checked automatically; and analysis tools can consume the model rather than a human reading of it.

SysML v2 is the substantive change here. Version 1 of the Systems Modeling Language was defined as a profile of UML, a software notation, and inherited both its ambiguity and its awkwardness for systems work. Version 2 is built on a new semantic foundation, the Kernel Modeling Language (KerML 1.0), and ships with a textual notation alongside the graphical one plus a standard API for model interchange. The OMG announced final adoption of SysML 2.0, KerML 1.0, and the Systems Modeling API and Services 1.0 in July 2025 (OMG, 2025); the open-source reference implementation and specification releases are maintained publicly, and the specifications were prepared editorially in March 2026 for submission to ISO (Systems Modeling Community, 2026). SysML v1.4 had previously been ratified as ISO 19514:2017, so an ISO route for v2 is a plausible continuation rather than a novelty.

For practitioners, the textual notation and the API matter more than the new diagrams. A text-based model can live in version control, be reviewed as a pull request, and be checked in continuous integration. That places systems modelling inside the workflow software engineers already have, which is the single most important precondition for it becoming routine rather than ceremonial.

---

What the evidence actually shows

This is where responsible reporting has to slow down.

Systems engineering as a practice. The most cited empirical work is a survey programme run by the Software Engineering Institute with the National Defense Industrial Association. Its analyses found statistically meaningful relationships between the deployment of systems engineering practices and project cost, schedule, and scope performance, with the relationship strongest when project difficulty was accounted for (Elm & Goldenson, 2012). The limitations are equally important: samples were modest, participation was voluntary, performance data was self-reported, and the design is correlational. Capable organisations may simply do both good systems engineering and good project management. The finding supports the discipline; it does not license precise claims about return on investment.

MBSE specifically. A systematic review of the systems engineering literature by Henderson and Salado (2021) categorised the evidence behind claimed MBSE benefits and found that roughly two-thirds were supported only by perceived evidence — asserted without measurement — while only two of the reviewed papers reported measured evidence. Their conclusion was that claims about MBSE's value remain largely expectation-based. Subsequent work by the same research group has focused on building measurement frameworks for digital engineering precisely because that gap persists (Henderson et al., 2022).

Two honest readings coexist. The first: absence of measured evidence is not evidence of absence, and measuring engineering method effects on multi-year programmes is genuinely hard, since there is no control group. The second: an industry that has spent a decade asserting benefits without instrumenting them has weakened its own case. Both readings point to the same recommendation — instrument your own adoption.

Outcomes at portfolio level. In its 24th annual assessment of major US weapon programmes, published 2 July 2026, the GAO reported that the average time frame to deliver a capability had risen to more than 12 years, that key milestones were being deferred without revised delivery dates, and that programmes were not consistently applying leading product-development practices; GAO also noted it has recommended since 2022 that the Department update its systems engineering and digital engineering policies to reflect iterative development (GAO, 2026). Digital engineering mandates alone have not yet moved portfolio-level outcomes.

---

Policy, the digital thread, and why procurement is driving adoption

DoD Instruction 5000.97, effective 21 December 2023, established digital engineering policy for US defence acquisition: programmes beginning after that date are to incorporate digital engineering during development unless the decision authority grants an exception, and earlier programmes are encouraged to adopt it where practical and affordable, with digital engineering addressed in the acquisition strategy and the systems engineering plan (US Department of Defense, 2023). The Department's own summary describes a framework spanning a digital ecosystem, digital models, digital twins, a digital thread, and digital artefacts (DoD CTO, 2024).

The digital thread is the connective concept: an authoritative, traceable flow of technical data across requirements, design, analysis, manufacture, and sustainment. It is best understood as a data-integration ambition rather than a product. The digital twin — a model of a specific instance kept current with operational data — is a downstream capability that depends on that thread existing.

Regulated civil sectors are converging on similar practices for different reasons. Medical device, automotive functional safety, rail, and nuclear regimes all require demonstrable traceability from hazard analysis through requirements to verification evidence; a well-formed model is a more defensible way to produce that evidence than a document set assembled at audit time.

---

Latest developments

Dated items, with evidence status marked.

• 21 December 2023 — DoDI 5000.97 takes effect. Established fact; the instruction is public (US Department of Defense, 2023).
• May 2023 — ISO/IEC/IEEE 15288 second edition published. Established fact; includes a new annex addressing MBSE (ISO/IEC/IEEE, 2023).
• July 2025 — SysML v2 final adoption announced by OMG, alongside KerML 1.0 and the Systems Modeling API and Services 1.0 (OMG, 2025). Established fact. Vendor conformance and enterprise migration timelines are not settled and vary by tool.
• March 2026 — SysML v2 specification documents editorially updated for submission to ISO (Systems Modeling Community, 2026). Established fact; ISO ratification itself is a future outcome, not a completed one.
• 2 July 2026 — GAO publishes its 24th weapon systems annual assessment (GAO-26-108457), reporting a portfolio average exceeding 12 years to deliver capability and continued under-use of leading practices (GAO, 2026). Established fact about the report's findings.
• 2025 — first published benchmarks for AI-generated system models. A benchmark of 17 large language models on generating system models from natural-language requirements reported weak performance, with the best BLEU score around 4% (Jin et al., 2025). Preliminary research finding, single benchmark, not yet replicated.
• 2025 — experimental studies of LLM-assisted SysML v2 modelling. Work presented at the INCOSE International Symposium reported that models could produce usable skeleton structures but that relying on them for complete model generation was not advisable owing to errors and inconsistencies (Rafique et al., 2025). Preliminary; small-scale.

Interpretation. The direction of travel — model-based, tool-interoperable, policy-mandated — is well established. The magnitude and timing of benefit is not. Claims that AI will shortly automate systems modelling are, on current published evidence, forecasts rather than findings.

---

An adoption path that survives contact with reality

Organisations that fail at MBSE usually fail the same way: they buy a tool, model everything, and discover eighteen months later that the model is a parallel artefact nobody's decisions depend on. The following maturity framing, developed for this article, describes a staged alternative.

Practical sequencing that reflects how successful adoptions tend to run:

1. Choose one decision the model must improve — for example, interface change impact assessment — and make the model the required input to that decision.
2. Model the interfaces first, not the functions. Interfaces are where document-based approaches fail hardest, so the benefit appears soonest.
3. Baseline your metrics before you start. Requirements volatility, defects found at integration versus in service, and rework hours are all measurable without new tooling.
4. Put the model in version control and treat modelling conventions as reviewed engineering standards.
5. Fund the modelling role explicitly. Where MBSE is added to existing workloads without allocated effort, it degrades to a documentation exercise.

---

Myths, misconceptions, and mistakes to avoid

• "Systems engineering means the V-model." The V is one life-cycle depiction; 15288 explicitly prescribes none and expects iteration and recursion.
• "MBSE replaces requirements." It changes where requirements live and how they are checked. Poorly written requirements remain poorly written inside a model.
• "A digital twin is an advanced 3D model." A twin is defined by its live coupling to a specific physical instance, not by visual fidelity.
• "SysML v2 makes existing models obsolete." Migration is a real project. Assess it as one, with a transformation and coexistence plan.
• "More process reduces risk." Unnecessary tailoring inflates cost and encourages the compliance theatre that hides real risk. 15288 is designed to be tailored.
• The most consequential mistake: allowing an operating assumption about human behaviour to go unvalidated. The international review of the Boeing 737 MAX flight control system, submitted to the FAA on 11 October 2019, found among other things that the certification analysis had leaned on single worst-case scenario reasoning that did not cover the relevant failure modes, and that flight-crew responses in the accidents diverged from the design assumptions used (JATR, 2019). It is a systems engineering failure of validation, not of component design.

---

Barriers, risks, and wider implications

Workforce and skills. Systems engineering competence is built on programme experience, which is scarce and slow to accumulate. INCOSE's own long-range vision identifies workforce development as a central constraint on the discipline's future (INCOSE, 2021).

Commercial and contractual friction. Model-based delivery raises questions that document-based delivery did not: who owns the model, what is deliverable at each milestone, and how a supplier's model is verified without exposing proprietary design detail. The Systems Modeling API is a technical enabler here, not a commercial answer.

Security. A connected digital thread aggregates the most sensitive description of a system in one queryable place. Access control, supply-chain assurance for modelling tools, and export-control classification of model content deserve explicit treatment in the engineering plan rather than delegation to IT.

Ethics and accountability. As AI-generated artefacts enter engineering baselines, provenance becomes a safety question. Any AI-assisted modelling workflow should record what was generated, by which model version, and who reviewed and accepted it — because accountability for a released system cannot be delegated to a generator.

Environment. Systems engineering methods are directly relevant to decarbonisation programmes, where whole-life trade-offs between embodied carbon, efficiency, and durability must be reasoned about explicitly. This is an area where the discipline's methods are mature but its application remains uneven.

---

Figure briefs for the OneWise design team

Figure 1 — "Where systems engineering intervenes across the life cycle." Purpose: Show that SE processes are continuous, not a front-end phase. Components: A horizontal band divided into six life-cycle stages (Concept, Development, Production, Utilisation, Support, Retirement). Above the band, four stacked lanes labelled Agreement Processes, Organisational Project-Enabling Processes, Technical Management Processes, Technical Processes, each drawn as a continuous bar with varying thickness across stages to indicate intensity. Relationships: Curved feedback arrows returning from Utilisation and Support to Concept and Development, labelled "operational feedback" and "change requests". Hierarchy: Lanes in muted tones; feedback arrows in the accent colour. Caption: "Life-cycle process groups are applied concurrently and recursively, not sequentially."

Figure 2 — "Document-based versus model-based sources of truth." Purpose: Make the single-source-of-truth argument concrete. Components: Two side-by-side panels. Left: five document icons (Requirements Spec, ICD, Architecture Doc, Test Plan, Trade Study) connected by dashed bidirectional arrows labelled "manual consistency". Right: a central model repository icon with solid arrows radiating outward to the same five artefacts, each labelled "generated view". Labels: Left panel "Consistency maintained by people"; right panel "Consistency maintained by the model". Caption: "The change is not fewer documents — it is where authority sits."

Figure 3 — "MBSE adoption staircase with measurement checkpoints." Purpose: Give leaders a staged plan. Components: Five ascending steps labelled Stage 0 to Stage 4 as in the maturity table. Annotations: A small clipboard icon on each step listing one metric to capture (e.g. Stage 1: "interface defects found before integration"). Visual hierarchy: Steps in increasing colour saturation; a dashed horizontal line across Stage 2 labelled "most organisations should stop and measure here before proceeding". Caption: "Staged adoption with measurement at each step, rather than enterprise transformation."

---

Practical takeaways

For practising engineers. Learn 15288's process vocabulary — it is the shared language in contracts and audits. Learn SysML v2's textual notation before its diagrams; it is faster to acquire and more useful in review workflows. Treat traceability as engineering evidence you will be asked to defend, not administrative overhead.

For technical leads. Define modelling conventions and enforce them in review. Decide explicitly, in writing, which artefacts the model is authoritative for and which remain document-based; ambiguity here is the main cause of dual-source-of-truth failures. Model interfaces first.

For engineering and programme managers. Do not fund MBSE as a tooling purchase. Fund it as a scoped capability change with baselined metrics, allocated effort, and a defined decision it must improve. Ask suppliers what their SysML v2 migration plan is and what evidence they can produce for model quality — not merely which tool they hold licences for.

For everyone. When you encounter a benefit claim about MBSE or digital engineering, ask what was measured, against what baseline, on what kind of programme. The published literature suggests that question is asked far too rarely.

---

Key insights

1. Systems engineering exists to control the interfaces and assumptions between components — not to add process for its own sake.
2. ISO/IEC/IEEE 15288:2023 is the international process baseline and explicitly prescribes no life-cycle model.
3. The V-model is a teaching diagram, not a standard requirement.
4. ISO/IEC/IEEE 42010:2022 governs how architecture is described, which is distinct from the architecture itself.
5. SysML v2, KerML 1.0, and the Systems Modeling API reached final OMG adoption in 2025; migration from v1 is a real project.
6. Textual notation and a standard API matter more for daily practice than new diagram types.
7. Evidence for systems engineering as a discipline is reasonably supportive but correlational.
8. Evidence for MBSE's specific benefits is weak and largely expectation-based, according to systematic review.
9. Policy — notably DoDI 5000.97 — is currently a stronger adoption driver than measured benefit.
10. AI assistance in systems modelling is at the prototype stage; published benchmarks show unaided generation of valid models is not yet reliable.

---

Frequently asked questions

What is systems engineering in simple terms? It is the engineering discipline concerned with the system as a whole: defining what the system must do, deciding how responsibilities are divided among its parts, controlling the interfaces between those parts, and verifying that the assembled result meets the agreed need.

What is the difference between systems engineering and software engineering? Software engineering builds software elements. Systems engineering governs the whole, which may include hardware, software, data, people, facilities, and services, and is responsible for the interactions between them.

Which standard defines systems engineering processes? ISO/IEC/IEEE 15288, currently in its second edition (May 2023). It defines life-cycle processes across agreement, organisational project-enabling, technical management, and technical process groups.

What is MBSE? Model-based systems engineering: an approach in which a formal, machine-readable model — rather than a set of documents — is the authoritative source of system definition, with documents generated as views of that model.

Is MBSE proven to save money? Not in the strong sense. A systematic literature review found most claimed benefits rested on perceived rather than measured evidence (Henderson & Salado, 2021). Organisations should measure their own adoption rather than rely on generic claims.

What is SysML v2 and how does it differ from SysML v1? SysML v2 is the second major version of the Systems Modeling Language. Unlike v1, which was a UML profile, v2 rests on the Kernel Modeling Language, adds a textual notation alongside graphical notation, and defines a standard API for tool interoperability.

Is SysML v2 an ISO standard? Not yet. It was adopted by the Object Management Group in 2025, and the specifications were prepared in March 2026 for submission to ISO. SysML v1.4 was previously ratified as ISO 19514:2017.

Do I have to migrate from SysML v1 to v2? Not immediately, and not without planning. Treat migration as a scoped project with a transformation approach and a coexistence period, and check your tool vendors' conformance timelines.

What is a digital thread? A connected, traceable flow of authoritative technical data across the life cycle — from requirements through design, analysis, manufacture, and sustainment.

What is a digital twin, and how is it different? A digital twin is a model of a specific physical instance that is kept current with data from that instance. A digital thread is the data connectivity that makes twins feasible.

What is the V-model, and is it still relevant? It depicts decomposition and requirements definition on the left, integration and verification on the right. It remains a useful explanatory device, but treating it as a mandated sequence contradicts the iterative and recursive application described in 15288.

Is systems engineering only for defence and aerospace? No. Its methods are applied in healthcare technology, automotive, rail, energy, telecommunications, and large-scale infrastructure — anywhere multi-supplier complexity and safety or reliability obligations coexist.

What qualifications exist in systems engineering? INCOSE operates a tiered certification scheme (ASEP, CSEP, ESEP) based on its Systems Engineering Handbook. Many universities also offer specialist master's programmes.

Can AI write system models for me? Not reliably today. Published benchmarking of large language models on system-model generation reported weak results, and experimental studies suggest usefulness is currently limited to producing draft skeletons for human refinement.

What is the most common reason MBSE adoption fails? Modelling everything without tying the model to a decision anyone depends on. The model then becomes a parallel artefact that costs effort and changes nothing.

How much systems engineering effort should a programme budget? There is no reliable universal figure. Effort should be scaled to system complexity, novelty, and consequence of failure, and reviewed as those change. Treat any single quoted percentage with caution.

---

Glossary

• Architecture description (AD) — A structured artefact expressing a system's architecture, organised by stakeholder concerns and viewpoints; specified by ISO/IEC/IEEE 42010:2022.
• Digital artefact — Any machine-readable engineering output within a digital engineering ecosystem.
• Digital engineering — An engineering approach using integrated digital models and data as the primary means of defining, analysing, and communicating a system.
• Digital thread — The traceable connection of authoritative technical data across life-cycle stages.
• Digital twin — A model of a specific system instance maintained in correspondence with data from that instance.
• INCOSE — International Council on Systems Engineering; publisher of the SE Handbook and operator of the SE certification scheme.
• Interface control — The disciplined definition and management of boundaries between system elements.
• KerML — Kernel Modeling Language; the semantic and syntactic foundation beneath SysML v2.
• MBSE — Model-based systems engineering.
• MOSA — Modular open systems approach; a design and acquisition strategy favouring open, replaceable modules.
• Recursion (in 15288) — Applying the same processes at successively lower levels of system decomposition.
• SysML — Systems Modeling Language, standardised by the Object Management Group.
• Systems Modeling API and Services — An OMG specification defining a standard interface for exchanging and querying SysML v2 model data.
• Traceability — Recorded linkage among needs, requirements, design elements, and verification evidence.
• Validation — Confirmation that the system meets the stakeholders' actual need.
• Verification — Confirmation that the system meets its specified requirements.

---

References (APA 7th)

Standards

International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2022). ISO/IEC/IEEE 42010:2022 — Software, systems and enterprise: Architecture description (2nd ed.). ISO. https://www.iso.org/standard/74393.html

International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2023). ISO/IEC/IEEE 15288:2023 — Systems and software engineering: System life cycle processes (2nd ed.). ISO. https://www.iso.org/standard/81702.html

Object Management Group. (2025, July 21). Object Management Group approves final adoption of the SysML v2 specification [Press release]. https://www.omg.org/news/releases/pr2025/07-21-25.htm

Object Management Group. (n.d.). OMG SysML specifications. Retrieved 2026, from https://www.omg.org/sysml/specifications.htm

Systems Modeling Community. (2026). SysML v2 release [Software repository and specification releases]. GitHub. https://github.com/Systems-Modeling/SysML-v2-Release

Academic papers

Elm, J. P., & Goldenson, D. R. (2012). The business case for systems engineering study: Results of the systems engineering effectiveness survey (Special report). Software Engineering Institute, Carnegie Mellon University. https://www.sei.cmu.edu/documents/1917/2012_003_001_34067.pdf

Henderson, K., McDermott, T., Salado, A., & Van Aken, E. (2022). Towards developing metrics to evaluate digital engineering. Systems Engineering, 26(1), 3–31. https://doi.org/10.1002/sys.21640

Henderson, K., & Salado, A. (2021). Value and benefits of model-based systems engineering (MBSE): Evidence from the literature. Systems Engineering, 24(1), 51–66. https://doi.org/10.1002/sys.21566

Jin, D., et al. (2025). A system model generation benchmark from natural language requirements (arXiv:2508.03215). arXiv. https://arxiv.org/abs/2508.03215

Rafique, U., et al. (2025). Enhancing model-based systems engineering with large language models. INCOSE International Symposium, 35. https://doi.org/10.1002/iis2.70067

Schleifer, S., Lungu, A., Kruse, B., Goetz, S., & Wartzack, S. (2025). Large language model-based generation of use case diagrams from requirement specifications. INCOSE International Symposium, 35, 261–275. https://doi.org/10.1002/iis2.70015

Books and handbooks

National Aeronautics and Space Administration. (2016). NASA systems engineering handbook (Rev. 2, NASA/SP-2016-6105). NASA.

Walden, D. D., Shortell, T. M., Roedler, G. J., Delicado, B. A., Mornas, O., Yew-Seng, Y., & Endler, D. (Eds.). (2023). INCOSE systems engineering handbook: A guide for system life cycle processes and activities (5th ed., INCOSE-TP-2003-002-05). Wiley. ISBN 978-1-119-81429-0

Government and official sources

Joint Authorities Technical Review. (2019, October 11). Boeing 737 MAX flight control system: Observations, findings, and recommendations. Submitted to the Associate Administrator for Aviation Safety, US Federal Aviation Administration. https://www.faa.gov/sites/faa.gov/files/2021-08/Final_JATR_Submittal_to_FAA_Oct_2019.pdf

Office of the Under Secretary of Defense for Research and Engineering. (2024). DoD Instruction 5000.97, "Digital Engineering": Summary. https://www.cto.mil/wp-content/uploads/2024/01/info-dodi-500097-de-summary.pdf

US Department of Defense. (2023, December 21). DoD Instruction 5000.97: Digital engineering. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500097p.PDF

US Government Accountability Office. (2026, July 2). Weapon systems annual assessment: Requiring mature technologies could enable shift to rapid delivery (GAO-26-108457). https://www.gao.gov/products/gao-26-108457

Other authoritative sources

International Council on Systems Engineering. (2021). Systems engineering vision 2035. INCOSE. https://www.incose.org/publications/se-vision-2035

---

Editorial note: This article was researched from primary standards documents, peer-reviewed literature, and official government publications. Where evidence is preliminary, contested, or absent, that status is stated in the text. The author has no first-hand programme experience to claim on the specific implementations discussed; all assessments are derived from the cited sources.