Turn specifications into accountable engineering work

October 16 at 8:58 a.m. through October 23 at 8:55 a.m. EDT.

A specification is only the start of an engineering agreement. Someone must decide what it means for this design, retain the assumptions behind its numbers, allocate responsibility, and carry the resulting work through review. This week DDNA connects more of that chain. Outside DDNA, lunar vehicles, commercial space relays, and modular defense interfaces show why the agreement must survive changes in hardware, software, and operating context.

Inside DDNA#

Start with the specifications the design must meet#

New Project adds Start from specs alongside document-led and no-Intent starts. Select catalog standards, add design values and scope, describe intended use, and answer prompts about platform, operating conditions, transport, power, and users. Optional suggestions come from the catalog and require your acceptance.

The selected specifications become the project's first source, numbered for traceability and staged as its specifications mandate. Intent processing follows source preparation. The setup controls are visible in the released application; this edition has not independently exercised creation through completed Intent generation.

Enlarge

Fresh capture of the unsent setup form. No project was created and no engineering values were entered.

The merged standards integration also brings the pinned StandardsForge MIL-STD library into the catalog, with searchable source pages and revision context. Page evidence is distinct from extracted clauses: finding a standard does not automatically establish its applicability, tailor it, or certify the design. Catalog materialization has not been independently verified in production for this review.

Enlarge

The live form asks for engineering context before a specification becomes part of a project. Placeholder examples are product-owned text, not customer requirements.

Keep performance targets and their standing explicit#

The new Performance parameters register retains thresholds, objectives, units, current values, verification methods, ownership, and conflicting source values. It appears in the relevant ConOps, Architecture, and Test Strategy handoffs.

Value status—Proposed, Vendor-claimed, Demonstrated, Agreed, or Open—is separate from document review state. A reviewed document does not silently turn a vendor claim into an agreed engineering target. Non-agreed values remain marked for review; conflicting values retain their source context. Current measured values are treated as margin evidence rather than automatically as competing requirements.

Review requirements as an engineering set, not just well-written sentences#

Requirements generation and quality checks now use an INCOSE Guide to Writing Requirements v4 rule catalog. Wording review preserves numeric content and source relationships; candidates still held by blocking rules remain outside publication for review. Individual characteristics, set-level findings, source provenance, and existing-parent checks make the assessment more explicit.

Program obligations have their own tab and scope, rather than being mixed into the system-design set and its deliverable rows. Same-source duplicate handling and enumerated statements support a cleaner set without treating materially different obligations as interchangeable. Project-wide findings appear at project level instead of as repeated copies on every row. These checks support engineering judgment; they are not an INCOSE certification or proof of system adequacy.

Propose allocation, then accept the rows that belong#

System requirements can receive proposed allocations to existing architecture elements. A deterministic pass uses explicit engineering relationships; an optional requested model pass considers remaining unplaced requirements. Reviewers accept individual proposal rows, with requirement revisions and element identity checked before application.

Program obligations and external systems are not allocation targets. A project without eligible architecture explains that prerequisite. This proposes responsibility within the existing model; it does not automatically create derived subsystem requirements or approve the allocation for you.

Preserve the reviewer's contribution to Intent#

Regenerate preserves eligible human-written sections, including their headings and text, in their recorded position. Template section headings remain controlled, while reviewers can add their own sections without turning those additions into model-owned prose. The distinction keeps repeatable document structure and human review contributions together.

Organize the project tree without confusing folders with engineering authority#

Workspace folders organize top-level projects in the Projects list and switcher, with rename, drag-and-drop placement, and remembered expansion. A folder changes organization, not project permissions, Intent ownership, or repository identity; deleting it does not delete its projects.

Separate placement controls preview moving an existing project under a parent or folding an eligible imported-repository wrapper into a host as a firmware/software repository. Folding retains repository history and archives the wrapper; it is not reversible through an unfold action. Engineering work and release state can prevent placement rather than be discarded.

Projects started without Intent documents now open a dedicated Overview covering structure, requirements, verification, release, sources, and next steps. Repository connection forms belong on Repositories instead of standing in for that overview.

Find your work across projects, then work the plan#

Enlarge

Fresh production capture of My Tasks with no task records displayed. The image shows the controls and empty state, not a populated assignment workflow.

My Tasks is the cross-project entry point for assigned native tasks, engineering issues, and requirement-field work. Due-date groups and project filters help narrow the list; issue rows show titles, numbers, labels, and context. Task status changes use the current project task record rather than treating the cross-project index as a second authority.

Within a project, Your work prioritizes assigned work and gates awaiting your decision. Plan adds a phase outline with progress, dates, gate status, nested subtasks, and the existing planning views. Assignment changes connect to in-app notifications and configurable realtime, daily, or quiet email preferences. Alert delivery rechecks assignment and access; it does not grant either.

Keep engineering issues connected to repository work#

Issue creation uses the repository's live templates: sections, required fields, title prefixes, and labels follow the selected template. Linked accounts allow attribution to the person opening the issue. Templates can be selected through the form, Project Chat, or MCP.

Issues from the project record repository and active code repositories join the engineering issue list with repository identity intact. Linked state and assignment changes synchronize in both directions under recorded conflict rules. Imported issues retain their repository's content authority. The refreshed list/detail views add clear state, labels, responses, readable tables, task checkboxes, and repository-local issue-number links. These are issue workflows—not a new source of approval authority for requirements.

Read DDNA records from your own tools#

Enlarge

Fresh production capture of the Developers page. No key was generated, entered, or exposed; account navigation and project details are outside the crop.

The Developers page introduces a read-only API for accessible projects, native tasks, and engineering issues. Personal keys have selectable expiry, last-use information, and revocation. Each read observes the owner's current workspace and project permissions; these keys are not browser sessions or general-purpose write credentials.

The portal includes endpoint documentation, OpenAPI, and request examples. Lists are paginated and reflect current records, not a transactionally frozen export. Use an appropriately authorized destination for any project data you retrieve.

Give connected agents clearer task references#

MCP task tools accept visible project names or slugs, friendly task references, supported task links, and exact assignee-name matches. Ambiguous references require clarification rather than a guessed write. A cross-project My Tasks tool lists the caller's assigned native tasks.

Task reads return an edit token for field-checked updates: a change to an unrelated field need not invalidate the edit, while a changed field being written is refused. Strict version checks remain available. This is merged tool behavior; a full authenticated third-party agent session was not exercised for this edition.

Select Drive evidence explicitly#

Google Drive evidence selection uses Google's multiselect Picker and per-file authorization. Chosen source identities remain connected to import and manual Sync. Existing broad-discovery connections require reconnection and file reselection; this is selected-file access, not unrestricted Drive search or a new approval to transfer controlled data.

Keep team membership and project access distinct#

Team & Access can keep a named team member off a particular restricted project while retaining their team membership and its other projects. Excluded people appear in a separate list with restore controls. Workspace-wide access and owner/manager authority remain explicit boundaries: an exclusion is not a way to override them.

Spend less work on list views and keep the active controls clear#

Overview, requirements, and Formalize list reads avoid unnecessary full-record assembly, compact repeated field structures, and defer background refresh while their tab is hidden. Direct project links resolve to their canonical route with less duplicate page work. These are more efficient reading paths, not a claimed production-wide speed multiplier.

The standalone Repositories page uses the same organized panel layout as Projects. On the System map, expanded and focused connection panels stay above neighboring edge controls while you edit.

Engineering radar#

Lunar mobility puts the operator inside the interface review#

Enlarge

Artist’s concept of lunar surface operations, not a photograph of deployed hardware. Credit: NASA. Image source

NASA's October 20 rover update describes crew evaluations with spacesuit mockups and pressurized suits, alongside planned wheel/soil testing. The report joins human reach, displays, mobility, power, and extreme-environment operation; a hardware mockup answers different questions from a flight article. For DDNA's thesis, the relevant connection is preserving intended use and the configuration behind each review result—not claiming these vehicles use DDNA. NASA lunar rover update

Commercial relay demonstrations move into orbit#

NASA reported the October 20 launch of Viasat and SES Space and Defense communications demonstrations. Planned tests combine high- and low-rate services across spacecraft, relay orbits, and ground stations. Launch establishes an opportunity to test, not demonstrated uninterrupted service. The engineering consequence is a verification boundary spanning more than the terminal: service behavior and command delivery need configuration-aware evidence. NASA communications demonstration launch

A modular defense interface reaches soldiers' hands#

Enlarge

PC-C6 experimentation, July 2026; the Army published the account in October. Credit: U.S. Army / Staff Sgt. Dane Howard. Image source

An Army report published October 21, bylined October 20, describes July PC-C6 experimentation with Picatinny CLIK. The interface brings attachment, power, communications, and safety-related commands into a common architecture. It is a newly published account of an earlier demonstration, not a new October test or universal interoperability certification. The DDNA-relevant engineering problem is retaining the exact interface/configuration and evidence for each permitted combination. Army CLIK experiment report

Wild card — the power plant is part of the spacecraft design#

Enlarge

SR-1 Freedom power-module concept illustration. This is a development rendering, not a flight photograph. Credit: NASA / Alberto Bertolin. Image source

NASA's October 20 SR-1 Freedom update assigns closed-Brayton-cycle power conversion work to Sierra Lobo for integration with an Idaho National Laboratory fission reactor. This is development and contract progress, not a flight demonstration. The engineering implication crosses thermal rejection, power conversion, structure, propulsion, and safety: one subsystem's operating assumptions become another's design inputs. The broader DDNA opportunity is preserving those cross-disciplinary agreements and decisions; DDNA is not claimed to perform nuclear safety analysis. NASA nuclear power module update

What to watch — the engineering agreement becomes executable#

1. A performance number needs an agreement state#

Strategic guidance context: INCOSE's GtWR v4 summary, June 2023, separates well-formed statements from the underlying analysis and an agreed obligation. It is not a newly issued defense mandate. The engineering consequence is larger than replacing vague words: a proposed range, a supplier claim, a demonstrated result, and an agreed threshold describe different evidence states even when they contain the same number. INCOSE v4 summary

Our analysis is that MBSE needs to preserve that distinction as values travel from source tables into allocations and verification plans. DDNA's new parameter register provides an inspected implementation step toward coherent program state; it does not settle feasibility or stakeholder agreement automatically.

Watch for design reviews that retain the source and status of each governing value, explicit decisions resolving competing targets, and verification criteria tied to the accepted revision. A clean sentence with no accepted basis is the counter-signal. Better wording can improve a requirement; only the responsible engineering authority can make the agreement.

2. Human-fit evidence belongs in the model's allocation story#

The new lunar-rover report makes an otherwise abstract MBSE problem tangible: a suited operator reaches a control, reads a display, enters a vehicle, and performs the intended task. A cabin dimension can pass inspection while the operational interaction remains unsuitable. NASA describes distinct mockup and future mobility evaluations; those are not interchangeable acceptance results. Rover evaluation context

Our analysis is that architecture allocation should carry the user task, interface, operating condition, and evidence method—not merely place a requirement under a component. DDNA can preserve engineering relationships and reviewed allocation proposals today. A future extension would connect human-in-the-loop observations to the precise mockup, suit assumptions, and design decision; that integration is not claimed here.

Watch for reviews tracing an observed usability limitation to an owned interface decision, planned retest against a new revision, and clear separation of mockup findings from flight qualification. More diagrams without an accountable action or applicable configuration would weaken the value of the digital model.

3. Shared infrastructure needs service-level acceptance evidence#

The new commercial relay launch shifts the verification question from a box to a service chain. High-rate science delivery and low-rate command links may traverse different relay paths. The important requirement is not simply that every component passes its own test, but that the assembled service behaves acceptably during the operating transitions that matter. NASA describes tests ahead, not proof that those transitions already satisfy mission acceptance. Relay demonstration context

For DDNA's execution-layer thesis, this raises the need for explicit boundary ownership: which interface, configuration, operating condition, and test result supports the delivered service claim? That is distinct from last week's RF coexistence modeling question; here the focus is responsibility and acceptance across a provider chain, not interference prediction.

Watch for end-to-end delivery and continuity results, defined command-service acceptance conditions, and evidence that remains meaningful when a provider path changes. A launch announcement or nominal link test alone would be a counter-signal. DDNA does not operate or certify these relay networks.

Where does your engineering record still confuse a stated target with an agreed obligation? That is a useful place to start the next review.