Design-OS: A Specification-Driven Framework for Engineering System Design with a Control-Systems Design Case
| Authors | H. Sinan Bank et al. |
| Year | 2026 |
| Field | AI / ML |
| arXiv | 2603.20151 |
| Download | |
| Categories | cs.CE, cs.AI |
Abstract
Engineering system design -- whether mechatronic, control, or embedded -- often proceeds in an ad hoc manner, with requirements left implicit and traceability from intent to parameters largely absent. Existing specification-driven and systematic design methods mostly target software, and AI-assisted tools tend to enter the workflow at solution generation rather than at problem framing. Human--AI collaboration in the design of physical systems remains underexplored. This paper presents Design-OS, a lightweight, specification-driven workflow for engineering system design organized in five stages: concept definition, literature survey, conceptual design, requirements definition, and design definition. Specifications serve as the shared contract between human designers and AI agents; each stage produces structured artifacts that maintain traceability and support agent-augmented execution. We position Design-OS relative to requirements-driven design, systematic design frameworks, and AI-assisted design pipelines, and demonstrate it on a control systems design case using two rotary inverted pendulum platforms -- an open-source SimpleFOC reaction wheel and a commercial Quanser Furuta pendulum -- showing how the same specification-driven workflow accommodates fundamentally different implementations. A blank template and the full design-case artifacts are shared in a public repository to support reproducibility and reuse. The workflow makes the design process visible and auditable, and extends specification-driven orchestration of AI from software to physical engineering system design.
Engineering Breakdown
Plain English
This paper introduces Design-OS, a five-stage specification-driven workflow for engineering system design that bridges the gap between human designers and AI agents working on physical systems (mechatronic, control, embedded). The core problem is that traditional engineering design is ad-hoc, with implicit requirements and poor traceability from intent to implementation parameters. The authors propose using explicit specifications as a shared contract between humans and AI at each stage—concept definition, literature survey, conceptual design, requirements definition, and design definition—rather than having AI enter only at solution generation. This represents a shift toward systematic human-AI collaboration for the entire design pipeline rather than isolated point interventions.
Core Technical Contribution
The key novelty is reframing the human-AI collaboration problem from solution-finding to problem-framing in physical system design. Unlike existing AI tools that focus on code generation or parameter optimization, Design-OS provides a systematic framework where specifications act as formal contracts that guide both human reasoning and AI assistance across the entire design lifecycle. The framework explicitly stages the design process in five distinct phases, each with defined inputs, outputs, and AI/human responsibilities, making the usually opaque design intent explicit and traceable. This represents the first formal specification-driven approach to systematically integrate AI agents into early-stage engineering design decisions for physical systems.
How It Works
Design-OS operates as a five-stage pipeline where specifications flow through and connect each phase: (1) Concept Definition: humans and AI collaboratively frame the problem space and define high-level design concepts with formal specifications; (2) Literature Survey: AI agents assist in searching and synthesizing relevant prior work guided by concept specifications; (3) Conceptual Design: specifications constrain and guide the generation of alternative design approaches; (4) Requirements Definition: abstract concepts are formalized into quantitative requirements, with AI helping identify constraints and dependencies; (5) Design Definition: detailed parameters and implementations are generated, constrained by all upstream specifications. At each stage, specifications serve as the single source of truth—humans update specs based on discoveries, and AI uses them to provide contextually relevant suggestions and validate consistency. The lightweight nature means it avoids heavy formal methods overhead while still maintaining traceability through explicit spec versioning and stage-to-stage validation.
Production Impact
Adopting Design-OS would fundamentally change how engineering teams organize the front-end of their design workflow, making AI a collaborative partner in problem framing rather than just solution generation. In practice, this means investment in specification infrastructure (likely YAML, JSON, or domain-specific languages) and training teams to externalize design intent early—this adds upfront overhead but reduces costly rework from implicit misunderstandings downstream. The specification-as-contract approach enables better handoffs between teams (mechanical, electrical, software) and creates an auditable record for compliance and regulatory requirements common in aerospace, medical devices, and automotive. The main trade-off is that this requires discipline to maintain specs throughout design evolution; teams skipping formalization will see little benefit. Integration complexity is moderate—this is a workflow process change, not a compute-intensive tool, so it can be gradually adopted into existing CAD/simulation toolchains.
Limitations and When Not to Use This
The paper does not address how to handle highly novel design spaces where prior specifications don't exist or how to automatically learn what specifications matter for a given domain—it assumes humans can articulate meaningful spec constraints upfront. Design-OS assumes synchronous, tightly-coupled human-AI iteration; in large distributed teams or when AI compute resources are constrained, latency and communication overhead may become prohibitive. The framework is tested only on traditional engineering domains; its applicability to rapidly-evolving fields like robotics or quantum system design, where specifications themselves are research frontiers, remains unclear. The paper lacks quantitative validation data: there is no ablation study showing which stages provide the most benefit, no comparison to ad-hoc baselines, and no measurement of time-to-design, error reduction, or team satisfaction, making it difficult to assess ROI in production adoption.
Research Context
This work builds on a growing literature in human-in-the-loop AI and AI-assisted design, but distinguishes itself by focusing on physical systems rather than software where spec-driven approaches are mature. It relates to formal methods and model-based systems engineering traditions (MBSE) but proposes a more lightweight, AI-friendly variant. The paper opens a research direction in specification semantics—how to make specs machine-parseable and actionable without drowning in formalism—and in multi-agent reasoning where different AI agents own different design stages and must respect shared contracts. It also bridges the gap between generalist LLM assistants (which dominate current AI-in-engineering) and domain-specific design tools, suggesting that structured workflows around explicit specs may unlock more reliable AI contributions.
:::tip Subscribe Get weekly breakdowns of papers like this in AI Letters - the newsletter for engineers building production AI systems. :::