---
title: Design-State Graph (DSG) in Engineering
url: https://www.emergentmind.com/topics/design-state-graph-dsg
type: topic
---

# Design-State Graph (DSG) in Engineering

Searching arXiv for the cited Design-State Graph paper and closely related graph-based design/system-engineering work to ground the article.
Design-State Graph (DSG) denotes, in the context of agentic conceptual systems engineering, a typed, directed multigraph \(G=(V,E)\) whose vertices are design nodes and whose edges denote flows of mass, energy, or information [2507.08619]. In that formulation, DSG is a JSON-serializable design artifact intended to persist across iterative large-language-model workflows, so that requirements, physical embodiments, and Python-based physics models remain co-located within a single machine-readable representation rather than being repeatedly regenerated as free-form text [2507.08619]. The representation was introduced for early-stage engineering design, where requirements extraction, functional decomposition, embodiment selection, and simulator code generation must be coordinated across multiple iterations [2507.08619].

## 1. Definition and representational scope

In the cited systems-engineering formulation, the DSG is defined as a typed, directed multigraph \(G=(V,E)\) whose vertices \(v \in V\) are design nodes and whose edges \((v_i,v_j)\in E\) denote flows of mass, energy, or information [2507.08619]. Each node is meant to be a small, self-contained piece of the system and bundles three classes of content: the function or sub-function it realizes, its physical embodiment, and one or more executable physics or simulation models [2507.08619]. The stated purpose is “to promote abstraction and decomposition by the LLM agents,” so that the system is broken into “core functionalities, their embodiments (systems, physical parts), and their numerical modeling scripts” [2507.08619].

The representation is explicitly positioned as a persistent design-state memory. The paper states that classic LLM interactions are effectively one-shot and tend to lose structure, traceability, and continuity across iterations, whereas the DSG is intended to preserve task continuity and traceability by allowing agents to read and write nodes rather than rewrite the entire design from scratch [2507.08619]. Because the DSG is JSON-serializable, it is also presented as suitable for programmatic manipulation, incremental graph mutation, and versioned workflow execution [2507.08619].

A useful implication is that the “state” in Design-State Graph refers not merely to static topology, but to the current engineering description of the artifact, including requirement links, embodiment choices, and embedded numerical models. This suggests a closer affinity to executable model-based design artifacts than to purely descriptive architectural diagrams.

## 2. Formal structure, node payloads, and serialization

The DSG schema is described through four conceptual data classes: `PhysicsModel`, `Embodiment`, `DesignNode`, and `DesignState` [2507.08619]. The graph-level structure is compact: vertices correspond to `DesignNode` objects, and the edge list is the single source of truth for connectivity [2507.08619].

| Element | Role in DSG | Key contents |
|---|---|---|
| `PhysicsModel` | Analytical or empirical model attached to a node | equation string, executable Python code, assumptions, status flag |
| `Embodiment` | Physical realization of a sub-function | principle keyword, narrative description, parameters with units, cost/mass estimates, status flag |
| `DesignNode` | Atomic element of the DSG | identifiers, one embodiment, list of physics models, requirement links, verification and maturity metadata |
| `DesignState` | Snapshot of the full DSG | map of node IDs to node payloads and flat edge list |

A `PhysicsModel` holds “(i) a LaTeX/plain-text equation string, (ii) executable Python code for simulation, (iii) a list of modeling assumptions, and (iv) a life-cycle status flag {draft, reviewed, validated}” [2507.08619]. An `Embodiment` captures “the current physical realization of the sub-function,” including a principle keyword such as “reverse-osmosis,” a brief narrative description, key design parameters with units, coarse cost and mass estimates, and a status flag [2507.08619]. A `DesignNode` aggregates those fields together with identifiers such as `node_id`, `node_kind`, `name`, and `description`, and includes traceability fields such as `linked_reqs`, verification plans, maturity level, and tags [2507.08619].

At the serialization level, a `DesignState` is described as a lightweight Pydantic data class containing a map from node identifiers to their full payloads and a flat edge list of the form `[[source,target]]` [2507.08619]. The agents are instructed to emit “exactly one JSON- or Python-serialized DesignState(...) object” per design, with all `DesignNode` entries fully populated and an `edges` list present [2507.08619]. The paper reports that “every experiment… maintained perfect JSON integrity,” indicating that this schema was consistently preserved across runs [2507.08619].

This architecture makes the DSG closer to a typed executable design record than to a graph used solely for neural message passing. The graph is the carrier of design semantics, and the node payload is the principal unit of engineering content.

## 3. Use in multi-agent and two-agent design workflows

The DSG serves as both shared memory and optimization target in the agentic workflow studied in “Agentic Large Language Models for Conceptual Systems Engineering and Design” [2507.08619]. Two orchestration regimes are compared: a nine-role multi-agent system (MAS) and a two-agent system (2AS) [2507.08619]. In both cases, the produced artifact is still a `DesignState`, but the organization of critique, code generation, and iteration differs substantially [2507.08619].

In the MAS configuration, the roles include Extractor, Supervisor, Generator, Coder, Reflector, Ranker, Meta-Reviewer, and Orchestrator plus Workers [2507.08619]. The workflow proceeds from requirements extraction to initial `DesignState` generation, followed by coding passes that turn node-level physics models into runnable Python scripts, then critique, ranking, meta-review, and further refinement cycles [2507.08619]. The paper states that each iteration modifies only part of the graph, because “each agent action mutates only the affected sub-tree,” so the DSG evolves incrementally rather than being replaced wholesale [2507.08619].

The 2AS ablation collapses this structure into a Generator–Reflector loop [2507.08619]. The Generator still outputs DSGs in `DesignState` format, while the Reflector handles critique, selection, and termination decisions [2507.08619]. The paper reports a qualitative difference in graph granularity: MAS with DeepSeek R1 70B generated more granular DSGs, averaging 5–6 nodes, whereas 2AS often “mode-collapses,” in some settings producing 1-node graphs on average [2507.08619]. MAS-generated node-level `PhysicsModel` entries also tended to be more elaborate, with “50+ line script[s] with CLI, logging, basic tests,” while 2AS outputs were often “5–15 line stub function[s]” without CLI, I/O, or tests [2507.08619].

A plausible implication is that the DSG functions not only as a representation but also as a coordination boundary: specialized agents can intervene on different substructures without requiring a monolithic redesign. The experiments suggest that orchestration quality materially affects how much structure the DSG actually acquires.

## 4. Requirements, embodiments, and executable physics models

A central property of the DSG is that requirements, physical embodiments, and executable models are represented within the same node structure rather than in disconnected artifacts [2507.08619]. Requirements are not encoded as separate nodes in the reported implementation. Instead, each `DesignNode` carries a `linked_reqs` field intended to store identifiers such as `"SR-01"` or `"SN-1"` [2507.08619]. For evaluation, requirement coverage is operationalized as the percentage of system requirements “mentioned in the DSG nodes,” calculated using regex pattern matching [2507.08619].

Embodiments are mandatory in practice in the reported experiments. Metric M3 is defined as the percentage of DSG nodes containing a physical embodiment, and M3 was 100% across all runs [2507.08619]. The solar-powered water filtration case includes embodiments such as “Flexible thin-film solar panels,” “Ceramic microfiltration,” “Low-weight DC diaphragm pump,” “Compact lithium-ion battery,” “Low-power microcontroller,” pH/turbidity/TDS sensors, an LCD-plus-buttons user interface, and a polypropylene enclosure [2507.08619]. These examples show the intended grain of decomposition: each node corresponds to a subsystem or sub-function with a concrete technological principle.

Executable modeling is embedded through the `PhysicsModel` field. The paper gives examples such as `solar_power.py`, `flow_rate.py`, and `pump_performance.py`, with governing expressions such as `P = eta * S * t`, `Q = (A * kappa) / mu`, and `Q = k * omega` represented in docstrings or comments and backed by runnable Python code [2507.08619]. In the MAS setting, the Coder agent is instructed to replace rough formulas with scripts that include CLI support via `argparse`, logging, output export, minimal tests, and coupling stubs for subsystem integration [2507.08619].

The synthesis of these three layers—requirements traceability, embodiment specification, and executable physics—distinguishes the DSG from representations that only capture architecture or only capture analysis. This suggests an attempt to collapse requirements engineering, conceptual embodiment, and early simulation into one graph-structured artifact.

## 5. Empirical behavior in the solar-powered water filtration case

The sole empirical case study reported for the Design-State Graph is a solar-powered water filtration system specified by a cahier des charges [2507.08619]. The experimental matrix spans 60 runs: two LLMs, two agent configurations, three temperatures, and five seeds [2507.08619]. Evaluation uses seven DSG-centered metrics: JSON validity, requirement coverage, embodiment presence, code executability, workflow completion, wall-clock time, and graph size [2507.08619].

Several outcomes are stable across all runs. JSON validity is 100%, and embodiment presence is also 100% [2507.08619]. Requirement coverage remains low: the paper states that it was “minimal (less than 20%)” overall, with the best observed value being 20% in a DeepSeek R1 70B, MAS, \(T=0.0\) setting [2507.08619]. Code compatibility is configuration-dependent. The highest executability reported is 100% for a specific 2AS setting, but the MAS average remains below 50% [2507.08619]. Only the reasoning-distilled model is said to reliably flag workflow completion [2507.08619].

The graph-size metric is especially informative for understanding what the DSG represented in practice. MAS with DeepSeek R1 produced DSGs averaging roughly 5–6 nodes, with best cases of 8 subsystem nodes [2507.08619]. The best 8-node MAS graph included solar generation, energy storage, power management, filtration, pump, sensors, user interface, and housing [2507.08619]. By contrast, the best 2AS graph contained four nodes—energy, flow/filtration, sensing, and battery/power management—and some settings collapsed to a single node [2507.08619].

The reported wall-clock behavior shows the trade-off between graph richness and simplicity. MAS runs with DeepSeek R1 are slower, around 650 seconds, while 2AS with DeepSeek R1 at \(T=0.0\) is around 39 seconds but yields 1-node DSGs [2507.08619]. This supports the paper’s conclusion that structured multi-agent orchestration enhances design detail, albeit with continued weaknesses in requirements mapping and code fidelity [2507.08619].

## 6. Relation to adjacent graph-based design representations and acronym ambiguity

The acronym DSG is not unique across the arXiv literature. In other works, DSG denotes “Dynamic Sequential Graph” in click-through-rate prediction [2109.12541], “dynamic scene graph” in text-to-video diffusion [2308.13812], and “Davidsonian Scene Graph” in text-to-image evaluation [2310.18235]. In multi-domain dialogue state tracking, a closely related but differently named construct is the “dialogue state graph” [2010.11137]. This indicates that “DSG” is an overloaded acronym rather than a standardized term.

Within engineering design specifically, the Design-State Graph has clear affinities with earlier graph-based design representations. “Complex System Design with Design Languages” describes a central “design graph” as the “unique abstract central-model of the product design,” represented as a UML instance diagram on which rules and process chains operate [1805.09111]. That design graph integrates structural objects, parameters, constraints, and links to CAD/CAE workflows, and the design process is described as a sequence of graph states transformed by rules [1805.09111]. The later Design-State Graph shares the same general ambition of maintaining a central, consistent, executable design representation, but the newer paper makes JSON serialization, embedded Python models, and LLM-agent manipulation first-class concerns [2507.08619].

The 2025 DSG also differs from the graph structures used in machine learning papers that happen to use the same acronym. In [2109.12541], the DSG is a lightweight ego subgraph with timestamps; in [2308.13812], it is a time-ordered list of scene graphs; in [2310.18235], it is a DAG of atomic visual propositions for evaluation. None of those uses refers to the typed, directed multigraph of design nodes, embodiments, and executable physics models introduced for conceptual systems engineering [2507.08619].

A common misconception, therefore, is to treat “DSG” as if it denoted a single canonical graph formalism. The literature supplied here shows that the acronym spans recommender systems, generative video, evaluation methodology, dialogue state tracking, and systems engineering, with only the 2025 paper using it to mean Design-State Graph [2507.08619].

## 7. Limitations, failure modes, and broader significance

The reported limitations are substantial and are explicitly tied to how the DSG is populated rather than to the JSON schema itself [2507.08619]. Requirement coverage is persistently low, usually 0% and at best 20%, even though each node has a `linked_reqs` field [2507.08619]. The paper notes that important requirements such as microbiological removal, environmental conditions, mass constraints, recyclability, and cost are often omitted [2507.08619]. This indicates that the presence of traceability fields alone does not ensure traceability.

Code quality is another bottleneck. Metric M4 checks only whether scripts compile and execute with `--help` or similar, which the paper identifies as Level-1 validity in a seven-level script-validation hierarchy [2507.08619]. Even runnable scripts can remain dimensionally or physically incorrect; examples mentioned include a solar model missing an area term and pump modeling issues involving specific gravity [2507.08619]. Graph connectivity is also described as sometimes shallowly reasoned: edges are “often declared but not coherently mapped to hierarchical dependencies” [2507.08619].

The comparison between MAS and 2AS reveals two distinct failure modes. The 2AS can undergo “mode collapse” in graph space, repeatedly emitting trivial one-node DSGs that satisfy the schema but fail to decompose the system [2507.08619]. The MAS, by contrast, can produce more granular graphs but still exhibit fragmentation, inconsistency across nodes, and elaborate code that does not translate into better physical correctness [2507.08619].

Despite these shortcomings, the representation is presented as domain-agnostic. The paper states that nodes, embodiments, physics models, and edges can in principle represent “turbomachinery, electronics, etc.,” although transferability beyond the single water-filtration case remains untested [2507.08619]. A plausible implication is that the conceptual contribution of the DSG lies in its representation design—integrating requirements, embodiments, and simulation scripts into a single graph artifact—while the principal unresolved problem is the reliability of autonomous population and refinement of that artifact by LLM agents.

In that sense, the Design-State Graph is best understood as a structured, executable state representation for early conceptual design: stable at the schema level, promising as an organizing abstraction, and not yet sufficient on its own to guarantee requirement-complete or physically rigorous engineering output [2507.08619].

Source: https://www.emergentmind.com/topics/design-state-graph-dsg