Digital engineering and the digital thread: a security question defense programs can't outsource

DoDI 5000.97 describes digital engineering as a means of using and integrating digital models and the underlying data to support a system's development, test and evaluation, and sustainment. The 2018 Department of Defense Digital Engineering Strategy describes how applying that practice can modernize acquisition. Digital models and digital artifacts can connect requirements, architecture, design, manufacturing, test, and sustainment information, but the program defines the authoritative sources, baselines, and traceability it needs; the result is not necessarily one model set. The practice is intended to reduce errors and delays that come from re-deriving information at each program phase, and can help a program evaluate the downstream effect of a proposed design change.

DoDI 5000.97 describes a digital thread as an extensible and configurable analytical framework that connects authoritative data and orchestrates digital models and information across a system's life cycle. It supports access, integration, transformation, and lifecycle feedback; the scope varies by program. A thread may connect requirements, design, manufacturing and quality, test, and sustainment data through defined exchanges, and can span a prime, subcontractors, suppliers, or government program offices where the program requires it. It does not necessarily mean one record or one shared platform.

INCOSE describes model-based systems engineering, usually abbreviated MBSE, as the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in conceptual design and continuing through development and later life-cycle phases. MBSE can produce a coherent system model and model-based artifacts, while text specifications and reports may remain part of the technical baseline. It is one digital method among others, alongside product lifecycle management and computer-aided design, and can contribute authoritative models and data to a digital thread; MBSE is not a mandatory prerequisite for a digital thread.

The DoD Systems Engineering Guide for Systems of Systems describes a system of systems as a set of independent systems, each useful in its own right, integrated to deliver a unique capability no single system provides alone. In defense, a sensor platform, a command-and-control network, and a weapon system may be connected across programs. Constituent systems can have different development, management, digital-engineering, data, and contractor arrangements; the interfaces between them create additional governance questions about what data crosses, at what fidelity, and under whose authority.

Because the risk is not confined to keeping outsiders out of a system. Every handoff in a digital thread can also be a point where an authorized party with the wrong scope of access, an unreconciled data version, or an unclear ownership boundary can quietly corrupt the data a program depends on for engineering decisions, contractual performance, and safety. A firewall or an access-control list configured well but assigned to the wrong owner, or scoped by convenience rather than by role and contract, still leaves the underlying governance question open. That governance question, who is accountable for the data at each handoff and who is allowed to touch it, needs to be addressed by the program's designated governance authorities, which may include program management, contracting, security, IT, and participating organizations.

General enterprise-architecture and data-governance guidance may start from a single organization that can define one data model, one access policy, and one change-control process. A defense digital thread can instead span a prime, subcontractors and suppliers, and government stakeholders, each running its own systems and answering to its own contract. Prime contracts and program policy may impose tool, format, access, and delivery requirements on subcontractors and suppliers, including digital models, artifacts, and datasets as contract deliverables; program offices may administer or revoke access in government-controlled environments. The appropriate governance model therefore depends on the program's actual authorities, contractual requirements, and data boundaries rather than assuming either full central control or complete organizational independence.

Lightbridge.ai's role here is that of an independent readiness advisor at the program-governance layer: helping a defense program assess and document who owns data integrity at each digital-thread handoff, how access should be scoped across a multi-contractor program, and how digital engineering practice fits the program's overall technology and risk strategy. The technical mechanics, identity and access management, network segmentation, and CUI-boundary architecture across a multi-contractor environment, are addressed in Lightbridge Cloud's DFARS and NIST 800-171 guide. Manufacturing-floor traceability specifics, including applicable lot or serial controls, configuration management inside a quality system, and first-production-run verification under AS9100D clause 8.5.1.3 (a properly performed AS9102 first-article inspection can address the representative-first-production-run element, but does not by itself establish full conformity with 8.5.1.3, which contains a separate production-process-verification requirement), are covered on this hub's AS9100 explainer. Engagement scope and requirements depend on the program and contract.