Release the Intent, preserve the decision
New Intent release controls, grounded need drafting, and hardware qualification evidence that stays tied to its configuration.
In this issue13 topics
Coverage: September 25 at 9:00 a.m. through October 2 at 9:01 a.m. EDT. Product updates below cover changes beyond the October 1 FY27 special edition.
An engineering decision needs a stable record: which needs were accepted, which assumptions held, and which revision the team approved. This edition follows that question into DDNA's new Intent release workflow and two physical systems crossing important test boundaries: a spacecraft with two propulsion modes and an autonomous vessel platform headed toward procurement.
Inside DDNA — what changed since the special edition#
Release the whole Intent package#
The Intent and Needs workflow previewed in the special edition is now implemented in the reviewed release. Intent uses 18 structured registers for stakeholders, problems, objectives, measures, scenarios, assumptions, constraints, interfaces, technical decisions, hazards, cyber risks, validation methods, and compliance applicability. Engineers can enter records directly or review AI proposals with source evidence. Controlled tables render into Intent documents from those records.
One editable working copy feeds immutable, revision-pinned release candidates. Documents, register entries, needs, and the requirements handoff move through Team & Access approval as a complete package. The approved release preserves the documents and revision manifest the team actually reviewed. Later editing starts from a working copy while the approved package remains intact.
Synthetic DDNA demonstration: an empty Intent Register shows mission groups, controlled entry fields, and AI proposal controls.
Review the combined set#
The preparation view brings register entries, needs, links, confirmations, and exceptions into the sign-off scope assigned through Team & Access.
Synthetic demonstration: combined sign-off scope, submission status, and findings. This empty set has not been submitted or approved.
Draft needs from reviewed engineering intent#
Intent and Needs now have separate navigation. Draft needs with AI uses reviewed register entries and retains links to the stakeholders, measures, validation methods, and problems behind each draft. Drafts use need language rather than requirement statements such as “shall.” A person accepts, edits, or rejects each proposal before it enters the controlled record.
Repeated tables now draw from a shared authority: Intent risk tables use Project Risks, Field Evaluation uses the MOE and MOP registers, Compliance uses Constraints, and approved trade-study decisions reach the technical-decisions register. Project Risks remains writable alongside DFMEA. DFMEA is enabled by default for workspaces that have not selected another state; administrators retain the audited setting.
Synthetic DDNA demonstration: the Needs Register shows Draft needs with AI and the review, stakeholder-confirmation, validation, and baseline indicators. No needs have been generated in this view.
Keep operational context and validation together#
The ConOps Register gives operational scenarios, modes, states, and steps a structured home. The Needs workspace also presents validation-result and risk-binding controls beside the needs they support.
Synthetic demonstration: operational context stays in structured registers. No operational scenario data is shown.
Synthetic demonstration: validation-result and risk-binding controls. No validation result or risk binding has been recorded.
Find and select Notion pages directly#
The Notion picker now searches a live page list, supports link lookup and multiple selections, shows parent context, orders recent edits, and supports keyboard navigation. Teams can choose the pages they intend to bring into the engineering record from the selection view.
Give board design and firmware separate release identities#
Board drill-down projects receive separate design-record and firmware repositories. Generated repository names identify the owning organization, project, and repository role. That gives hardware definition and firmware distinct identities as they evolve and release.
See AI and uploaded-source usage#
The Usage meter shows personal AI spend, token volume, and uploaded-source storage. Its detailed screen offers 7-, 30-, and 90-day views, daily spend or token charts, and breakdowns by feature, model, project, and storage, with wider workspace scope where permissions allow it. Tracking begins with this release; the meter does not backfill historical per-person usage.
More precise previews and a smoother System map#
MCP preview operations for evidence normalization and requirement differences are separately declared and constrained to project-owned data. System-map connections have cleaner routed geometry, and saving a connection reuses the engineering revision refresh. These changes improve the workflows introduced in the special edition without introducing a new measured performance claim.
Engineering radar#
Two propulsion modes, one integrated test article#
NASA reported on September 25 that its 6U ASCENT CubeSat completed leak, thermal-vacuum, and spin testing. A central tank feeds both chemical propulsion and electrospray thrusters. Shared propellant and plumbing connect two very different operating modes to the same mass properties, thermal environment, electronics, and attitude-control constraints. Ground testing provides evidence for the integrated flight article; it does not establish on-orbit performance. The DDNA-relevant engineering question is which configuration and operating envelope each result supports. NASA ASCENT testing
Maritime autonomy moves toward a production decision#
On September 29, the Navy announced plans to procure 30 Medium Unmanned Surface Vessels following Phase I at-sea testing. Evaluation included environmental understanding, autonomous navigation under collision regulations, and long-duration missions. The vessels are intended to host adaptable mission payloads. Each payload or autonomy change can affect power, machinery control, sensor coverage, communications, and the accepted mission envelope. A procurement announcement establishes a program decision, while fleet reliability and later payload integrations still require their own evidence. U.S. Navy MUSV announcement
What to watch — evidence that survives change#
1. Qualification needs an explicit applicability boundary#
ASCENT's two propulsion modes illustrate why a test result belongs to a particular article and configuration. A valve, firmware schedule, mounting change, or thermal interface can alter which evidence remains valid. As strategic context, active NASA-STD-7002B with Change 1, revalidated in 2023, provides a basis for payload test programs and discusses qualification-by-similarity pedigree. It is a NASA payload standard, not a universal defense obligation.
The DDNA thesis points toward carrying that pedigree with Product DNA: test conditions, instrumentation, hardware and firmware identities, similarity rationale, limitations, and the approval that accepted them. Watch for test reports carrying configuration identifiers and change reviews that explicitly decide which evidence transfers, which analysis must be repeated, and which hardware must be retested. A pass/fail label detached from that boundary is a weak basis for the next release. NASA-STD-7002
2. Modularity needs verified substitution#
The Navy's adaptable-payload framing raises a practical MBSE question: can a second payload replace the first within the same accepted envelope? Physical fit and a documented connector are only part of the interface. Power transients, cooling, timing, data semantics, electromagnetic compatibility, autonomy behavior, and operational procedures also matter.
DDNA's controlled interfaces and configuration record support the definition side of that problem. The larger thesis is to preserve the evidence behind a substitution as the change propagates across disciplines. Watch for multi-vendor swaps accompanied by interface-conformance results, updated allocations, and configuration-specific integration tests. The adoption signal is an accepted replacement with a traceable verification scope. A platform described as adaptable may still require substantial bespoke integration; the Navy announcement alone does not prove plug-and-play interoperability. Navy platform context
3. Standards can become versioned engineering obligations#
NIST's September 8 digitalized-standards update, revised September 9, describes single-source XML, explicit section identities, metadata, and direct ingestion by regulatory and field-inspection tools. This is strategic context from legal metrology, not a new defense mandate.
The mechanism is relevant to requirements and V&V: a stable clause identity can connect an obligation to its adopted revision, applicability decision, tailoring, owner, and acceptance evidence. Within the DDNA thesis, those links belong in the same controlled program state as the design. Watch for tools preserving source-clause identity through revisions, recording approved tailoring, and distinguishing a superseded obligation from one still governing a released configuration. Machine-readable delivery alone cannot settle ambiguous language or contractual applicability. Human engineering and approval decisions still determine what the product must prove. NIST digitalized standards
Which change in your product would force you to reopen an accepted engineering decision? That is where a controlled release record earns its value.