When the model reaches the hardware, what still counts as evidence?

This week, DDNA moved more engineering work into one connected program state: conversations that can become controlled changes, Intent documents that can carry editable visuals, product-oriented SysML output, and failure analysis tied to the requirements it is meant to protect.

The wider defense signal is just as clear. Autonomous systems are being coordinated at the edge, command-and-control software is being assembled from swappable applications, manufacturing is moving aboard ships, and sustainment organizations are compressing decisions across enterprise boundaries. The hard problem is no longer creating another model. It is preserving the chain from intent to configuration to physical evidence while the system changes.

Inside DDNA#

Engineering chat now works where the engineering happens#

Project-aware chat is available across Intent, Requirements, and the Workbench. Conversations retain private project history, use the selected project as context, and can draw on the project graph and scoped web research. When the assistant proposes a document change, the proposed edit remains reviewable before it becomes part of the program record.

That separation matters: a useful answer is not automatically an approved engineering decision. DDNA keeps the conversation, the proposed change, and the controlled record distinct.

Enlarge

Intent documents gained a visual engineering workspace#

Intent documents can now be organized in folders with references and visuals alongside the narrative. Teams can generate multiple visual candidates, refine a selected direction, and save either an image or an editable diagram into the document. The diagram workspace preserves nodes and relationships as something the team can inspect and change—not just a flattened illustration.

Generated visuals are working drafts. Their value comes from helping a team make operating concepts, interfaces, and sequences explicit before review.

Enlarge

Enlarge

Failure analysis is now relational#

DDNA's DFMEA workspace connects failure modes, causes, effects, controls, actions, decisions, and residual assessments to exact requirement revisions. The goal is a living engineering analysis: when the requirement or design basis changes, the team can see which risk reasoning needs review instead of treating a spreadsheet snapshot as timeless evidence. Structured JSON, CSV, and XLSX exports support downstream work without surrendering the controlled source record.

This is DDNA's engineering method; it does not by itself establish compliance with a particular industry FMEA standard or certify a design.

SysML output is becoming product-oriented#

The generated SysML v2 model now describes the product through definitions and usages, ownership, requirements, and relationships—not a restatement of the project-management process. It is produced from finalized requirements and checked against DDNA's supported textual subset. That makes it a stronger handoff into model-based work, while keeping an important boundary: syntactic validation is not proof that the model is complete or that the physical system satisfies its requirements.

Taken together, these improvements make DDNA less like a collection of documents and more like an execution layer: one connected state from mission intent through requirements, models, risk, decisions, and evidence.

Engineering radar#

Autonomy is becoming an integration problem at the tactical edge#

On September 10, the U.S. Army described an August demonstration in which DEVCOM Army Research Laboratory teams connected air and ground robotic platforms, real-time edge target tracking, resilient communications, and multi-agent autonomy. The public account emphasizes cross-cutting integration and translating operator intent into coordinated autonomous behavior—not a single isolated vehicle capability. U.S. Army

Our read: As autonomy moves from one platform to coordinated systems, the engineering baseline has to express more than component requirements. Mission intent, agent roles, communications assumptions, software configuration, platform constraints, and human authorization all influence what a demonstration proves.

The DDNA connection: DDNA's thesis is the program state around that integration: requirements allocated across hardware and software, decisions carried into changed configurations, and evidence tied to the exact system-of-systems arrangement tested. DDNA is not the autonomy stack or the tactical network.

Joint command software is being treated as a composable ecosystem#

Air Combat Command reported on September 9 that the latest DASH experiment used a government-owned orchestrator and applications from multiple vendors in an unclassified, plug-and-play environment. The team ran realistic scenarios and collected process metrics while preparing for transition into classified networks. The article reports the experiment and its objectives; it does not establish fielded operational performance. U.S. Air Force

Our read: A composable software ecosystem turns interface definitions, data meaning, version compatibility, cyber constraints, and scenario configuration into first-class engineering evidence. “It connected” is only the opening result. Teams still need to know which combination ran, under which assumptions, against which acceptance criteria.

The DDNA connection: The opportunity is to keep each application, interface decision, requirement, test configuration, and transition disposition connected as the ecosystem changes. That is software-defined hardware engineering: software choices reshape what the physical mission system can do and what must be reverified.

Sustainment speed is becoming a cross-enterprise data problem#

Air Force Global Strike Command's September 8 account of the North Star Readiness Campaign describes AFGSC, Air Force Materiel Command, and the Defense Logistics Agency coordinating B-1 and B-52 modernization and sustainment across parts, engineering, depot maintenance, and daily aircraft-on-ground decisions. The command reports that some lateral shipments moved from weeks to two or three days. U.S. Air Force

Our read: The interesting capability is not only faster logistics. It is the ability to make engineering and supply decisions across organizations without losing configuration identity. A substitute part, repair disposition, software load, or depot action must still resolve to the aircraft and acceptance basis it affects.

The DDNA connection: This is where an as-designed, as-built, and as-tested thread matters. DDNA's Reproducibility Packet thesis asks whether another authorized team can understand what changed, why it was accepted, and what evidence travels with the configuration.

Wild card: a factory workflow went to sea#

Naval Postgraduate School reported on September 8 that a shipboard additive-manufacturing effort during RIMPAC took a workflow from raw bar stock through powder production, printing, post-processing, inspection, and a usable metal part. The team used a Metal Powder Works M-175 system aboard ship and confronted conditions that a laboratory does not reproduce: motion, heat, placement, power, safety, communications, logistics, and schedule. U.S. Navy

Our read: The machine is only one element of the capability. The transferable unit is the qualified recipe: source material, machine and software configuration, environmental limits, process parameters, inspection method, acceptance criteria, and authorization to use the resulting part.

Why DDNA matters here: A reproducible defense-industrial base needs that complete chain to travel with the design. DDNA's role is the controlled engineering and evidence package around distributed production—not a claim that DDNA qualifies shipboard printers or manufactured parts.

What to watch: the next engineering stack is an evidence system#

These are strategic signals, not claims of completed DDNA integrations or automatic compliance.

1. SysML moves from documentation into the verification loop#

OMG positions SysML v2 as a language for requirements, behavior, structure, analysis, and verification, with formal semantics and a standard textual syntax. That creates the foundation for models that software can query and transform, not just diagrams people inspect. OMG SysML v2

A May 2026 research preprint goes one step further: its SHIA prototype connects SysML v2 structure to physical hardware and reports a Raspberry Pi logic-gate case with no observed discrepancy between modeled and physical behavior. It is a small experimental case, not general proof that model-to-hardware verification is solved. SHIA preprint

The big idea: A model becomes operational when a requirement, interface, or behavior can be traced to a configured test and a returned observation. But the loop must preserve identity: model revision, generated configuration, device state, stimulus, measurement method, acceptance rule, and result.

Watch for: hardware-in-the-loop demonstrations that survive configuration changes; results bound to exact model elements and requirement revisions; and discrepancy handling that creates controlled engineering work. The stronger signal is not automatic code generation. It is a defensible chain from intent to executable model to observed hardware.

2. FMEA becomes a living dependency network#

IEC 60812:2018 describes planning, performing, documenting, and maintaining FMEA/FMECA across hardware, software, processes, human action, and interfaces. It is deliberately generic and allows different criticality approaches; it is not a design certification. IEC 60812

The big idea: In a software-defined system, failure reasoning ages quickly. A new firmware load can alter timing and detection behavior without changing a drawing. A supplier substitution can change a material or process assumption without changing the top-level function. The useful FMEA is therefore not a frozen table; it is a network connected to requirements, interfaces, configurations, controls, evidence, and unresolved action.

Watch for: change events that automatically identify affected failure chains; residual risk reassessed against the released configuration; controls linked to evidence rather than prose alone; and explicit ownership for incomplete actions. DDNA's relational DFMEA is aimed at this controlled-change problem, while project tailoring remains necessary for any claimed standard conformance.

3. Requirements practice is becoming a moving standard, too#

ISO/IEC/IEEE 29148:2018 remains the published requirements-engineering reference and was confirmed in 2024, while ISO now marks it “to be revised” and lists a replacement draft under development. The standard covers requirements processes and information items across the lifecycle. ISO/IEC/IEEE 29148

The big idea: Requirements are not just sentences. They carry rationale, source, allocation, verification method, configuration applicability, and ownership. The standards that shape those practices also evolve. A durable program therefore needs both a controlled requirement baseline and a controlled interpretation of which contractual or organizational rules apply.

Watch for: machine-actionable requirement attributes that survive tool exchange; contract tailoring mapped to named evidence obligations; and migration plans that preserve decisions and history when standards or schemas change. “AI generated requirements” will matter far less than whether a team can show why each accepted requirement exists and how it will be verified.

4. Safety evidence becomes a managed decision chain#

MIL-STD-882E Change 1 remains the active Department of Defense system-safety reference in ASSIST. It establishes a system-safety approach centered on eliminating hazards where possible and reducing associated risk through the lifecycle. It applies when invoked and tailored by the relevant contract or program; it is not an automatic obligation for every project. DLA ASSIST

The big idea: In a fast-changing defense system, a hazard record must connect to the design decision, control, responsible owner, verification evidence, residual risk, and accepting authority. If software changes the behavior of a physical platform, safety reasoning must be re-evaluated against that combined configuration.

Watch for: hazard controls allocated into hardware and software requirements; verification results tied to the configuration they cover; residual-risk acceptance carried as a first-class decision; and automated impact analysis that proposes review without silently declaring safety. This aligns with DDNA's core thesis: one authoritative program state where decisions and evidence remain coherent as the product changes.

The question#

If your model changed tomorrow, could your team identify every physical configuration, failure analysis, test result, and approval that should be reconsidered—or would that evidence have to be reconstructed by hand?