Design-State Graph (DSG) in Engineering

• Design-State Graph (DSG) is a JSON-serializable, typed directed multigraph where nodes bundle design functions, physical embodiments, and executable simulation models.
• DSG enables traceability in iterative design workflows by preserving requirements links, simulation scripts, and physical specifications within a unified node structure.
• Empirical studies show DSG facilitates multi-agent coordination and incremental design while highlighting challenges in requirement coverage and code fidelity.

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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). 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” (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). Because the DSG is JSON-serializable, it is also presented as suitable for programmatic manipulation, incremental graph mutation, and versioned workflow execution (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). The graph-level structure is compact: vertices correspond to DesignNode objects, and the edge list is the single source of truth for connectivity (Massoudi et al., 11 Jul 2025).

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}” (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025).

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]] (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). The paper reports that “every experiment… maintained perfect JSON integrity,” indicating that this schema was consistently preserved across runs (Massoudi et al., 11 Jul 2025).

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 LLMs for Conceptual Systems Engineering and Design” (Massoudi et al., 11 Jul 2025). Two orchestration regimes are compared: a nine-role multi-agent system (MAS) and a two-agent system (2AS) (Massoudi et al., 11 Jul 2025). In both cases, the produced artifact is still a DesignState, but the organization of critique, code generation, and iteration differs substantially (Massoudi et al., 11 Jul 2025).

In the MAS configuration, the roles include Extractor, Supervisor, Generator, Coder, Reflector, Ranker, Meta-Reviewer, and Orchestrator plus Workers (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025).

The 2AS ablation collapses this structure into a Generator–Reflector loop (Massoudi et al., 11 Jul 2025). The Generator still outputs DSGs in DesignState format, while the Reflector handles critique, selection, and termination decisions (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). 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" (Massoudi et al., 11 Jul 2025). For evaluation, requirement coverage is operationalized as the percentage of system requirements “mentioned in the DSG nodes,” calculated using regex pattern matching (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). The experimental matrix spans 60 runs: two LLMs, two agent configurations, three temperatures, and five seeds (Massoudi et al., 11 Jul 2025). Evaluation uses seven DSG-centered metrics: JSON validity, requirement coverage, embodiment presence, code executability, workflow completion, wall-clock time, and graph size (Massoudi et al., 11 Jul 2025).

Several outcomes are stable across all runs. JSON validity is 100%, and embodiment presence is also 100% (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). Code compatibility is configuration-dependent. The highest executability reported is 100% for a specific 2AS setting, but the MAS average remains below 50% (Massoudi et al., 11 Jul 2025). Only the reasoning-distilled model is said to reliably flag workflow completion (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). The best 8-node MAS graph included solar generation, energy storage, power management, filtration, pump, sensors, user interface, and housing (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). This supports the paper’s conclusion that structured multi-agent orchestration enhances design detail, albeit with continued weaknesses in requirements mapping and code fidelity (Massoudi et al., 11 Jul 2025).

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 (Chu et al., 2021), “dynamic scene graph” in text-to-video diffusion (Fei et al., 2023), and “Davidsonian Scene Graph” in text-to-image evaluation (Cho et al., 2023). In multi-domain dialogue state tracking, a closely related but differently named construct is the “dialogue state graph” (Zeng et al., 2020). 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 (Vogel et al., 2018). 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 (Vogel et al., 2018). 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 (Massoudi et al., 11 Jul 2025).

The 2025 DSG also differs from the graph structures used in machine learning papers that happen to use the same acronym. In (Chu et al., 2021), the DSG is a lightweight ego subgraph with timestamps; in (Fei et al., 2023), it is a time-ordered list of scene graphs; in (Cho et al., 2023), 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 (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). Requirement coverage is persistently low, usually 0% and at best 20%, even though each node has a linked_reqs field (Massoudi et al., 11 Jul 2025). The paper notes that important requirements such as microbiological removal, environmental conditions, mass constraints, recyclability, and cost are often omitted (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025). Graph connectivity is also described as sometimes shallowly reasoned: edges are “often declared but not coherently mapped to hierarchical dependencies” (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025).

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 (Massoudi et al., 11 Jul 2025). 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 (Massoudi et al., 11 Jul 2025).