pith. sign in

arxiv: 2603.20151 · v2 · submitted 2026-03-20 · 💻 cs.CE · cs.AI· cs.SY· eess.SY

Design-OS: A Specification-Driven Framework for Engineering System Design with a Control-Systems Design Case

H. Sinan Bank , Daniel R. Herber , Thomas H. Bradley This is my paper

Pith reviewed 2026-05-15 07:04 UTC · model grok-4.3

classification 💻 cs.CE cs.AIcs.SYeess.SY
keywords specification-driven designengineering workflowhuman-AI collaborationcontrol systems designrotary inverted pendulumtraceabilityrequirements engineeringdesign process
0
0 comments X

The pith

Specifications serve as the shared contract between human designers and AI agents in a five-stage workflow for physical engineering systems.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Design-OS organizes engineering system design into five stages: concept definition, literature survey, conceptual design, requirements definition, and design definition. Specifications function as the bridge that keeps design intent explicit and traceable when humans hand off work to AI agents. Each stage outputs structured artifacts that support agent execution while preserving the chain from initial intent to final parameters. The approach is shown on a control-systems case with two rotary inverted pendulums that differ in hardware and software yet follow the identical workflow. This makes the design process visible, auditable, and reusable across open-source and commercial platforms.

Core claim

The paper introduces Design-OS, a lightweight specification-driven workflow for engineering system design organized in five stages that produces structured artifacts at each step. Specifications act as the shared contract between human designers and AI agents, enabling traceability from intent to implementation and supporting agent-augmented execution. The workflow is demonstrated on two fundamentally different rotary inverted pendulum platforms—an open-source SimpleFOC reaction wheel and a commercial Quanser Furuta pendulum—showing that the same stages accommodate distinct implementations while keeping the design process visible and auditable.

What carries the argument

The five-stage specification-driven workflow in which specifications serve as the explicit shared contract that generates traceable artifacts between human designers and AI agents.

If this is right

  • The design process for physical systems becomes visible and auditable at every stage.
  • AI agents can participate from problem framing onward rather than only at solution generation.
  • The same workflow applies without change to both open-source and commercial hardware platforms.
  • Traceability from initial requirements to final design parameters is maintained end to end.
  • Blank templates and shared artifacts enable direct reuse on new projects.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Design repositories could store prior specification artifacts so new projects start with reusable, machine-readable contracts.
  • The stages could be extended to multi-physics systems where specifications must coordinate mechanical, electrical, and software domains simultaneously.
  • Tooling that automatically checks consistency between stage artifacts would reduce the manual overhead of maintaining traceability.
  • Similar workflows might transfer to other domains such as embedded software or biomedical device design where human-AI handoff is also critical.

Load-bearing premise

Structured specifications can be written and read without losing essential design intent when they move between human designers and AI agents on different physical hardware.

What would settle it

Two separate teams applying the Design-OS workflow to the same rotary inverted pendulum problem produce final parameter sets that cannot be reconciled with the original intent or with each other.

read the original 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper presents Design-OS, a lightweight five-stage specification-driven workflow (concept definition, literature survey, conceptual design, requirements definition, design definition) for engineering system design. Specifications function as the shared contract between human designers and AI agents; each stage yields structured, traceable artifacts that support agent-augmented execution. The framework is positioned against requirements-driven and AI-assisted design methods and demonstrated on a control-systems case using two rotary inverted pendulum platforms (open-source SimpleFOC reaction wheel and commercial Quanser Furuta), showing that the same workflow accommodates fundamentally different hardware implementations. A blank template and full artifacts are provided in a public repository.

Significance. If the central claim holds, the work offers a practical, auditable structure for physical-system design that extends specification-driven methods from software into mechatronics and control, with potential to improve traceability and enable future AI collaboration. The qualitative demonstration across two dissimilar platforms and the public release of artifacts are concrete strengths that aid reproducibility.

major comments (2)
  1. [control systems design case / demonstration] The demonstration on the two rotary inverted pendulum platforms shows only human-generated artifacts and workflow steps; no AI agent (LLM prompting, interpretation of specifications, or reproduction of design decisions) is tested or reported. This leaves the claim that the artifacts 'support agent-augmented execution' and serve as a 'shared contract' between humans and AI agents as an untested assertion rather than an observed result, which is load-bearing for the paper's positioning of Design-OS.
  2. [Abstract and introduction] The abstract and introduction assert that the workflow 'extends specification-driven orchestration of AI from software to physical engineering system design,' yet the case study provides no evidence of AI participation or intent preservation across the human-AI boundary. This gap directly affects the soundness of the human-AI bridging mechanism.
minor comments (2)
  1. [introduction / related work] The positioning relative to existing systematic design frameworks and AI-assisted pipelines is stated but would benefit from a short explicit comparison table or additional citations to clarify distinctions.
  2. [figures and case-study artifacts] Figure captions and artifact descriptions could more explicitly label the traceability links between stages to make the contract mechanism visually clearer.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback highlighting the distinction between framework design and empirical validation of AI participation. We agree that the current demonstration is human-only and will revise the manuscript to clarify the scope of claims regarding agent augmentation while preserving the core contribution of the specification-driven workflow and its traceability properties.

read point-by-point responses

  1. Referee: [control systems design case / demonstration] The demonstration on the two rotary inverted pendulum platforms shows only human-generated artifacts and workflow steps; no AI agent (LLM prompting, interpretation of specifications, or reproduction of design decisions) is tested or reported. This leaves the claim that the artifacts 'support agent-augmented execution' and serve as a 'shared contract' between humans and AI agents as an untested assertion rather than an observed result, which is load-bearing for the paper's positioning of Design-OS.

    Authors: We acknowledge that the rotary inverted pendulum case study executes the five-stage workflow exclusively with human-generated artifacts and does not include LLM prompting, specification interpretation by agents, or reproduction of decisions by AI. The specifications are deliberately formatted as structured, machine-readable contracts (e.g., explicit intent statements, traceable requirements, and design parameters) precisely to enable future agent use, but this enabling property is shown only by construction rather than by experiment. We will revise the manuscript to state that Design-OS provides the artifact structure and traceability needed for agent-augmented execution, while noting that empirical testing of AI agents lies beyond the present scope and is planned as follow-on work. This revision will be reflected in the positioning section and conclusion. revision: yes

  2. Referee: [Abstract and introduction] The abstract and introduction assert that the workflow 'extends specification-driven orchestration of AI from software to physical engineering system design,' yet the case study provides no evidence of AI participation or intent preservation across the human-AI boundary. This gap directly affects the soundness of the human-AI bridging mechanism.

    Authors: The abstract and introduction currently use phrasing that implies active extension to AI orchestration. Because the case study demonstrates only the human workflow and the resulting artifacts, we will revise both sections to replace assertive language with phrasing that emphasizes the framework's design for such extension (e.g., 'provides a specification-driven foundation that can support orchestration of AI agents in physical engineering system design'). The revisions will also add an explicit limitations paragraph noting the absence of AI experiments in the present work. These changes will be made without altering the reported human demonstration or the public artifact repository. revision: yes

Circularity Check

0 steps flagged

No circularity: descriptive workflow with external case-study demonstrations

full rationale

The paper presents Design-OS as a five-stage specification-driven workflow (concept definition through design definition) whose central claim is that specifications act as a shared contract supporting traceability and agent-augmented execution. This is illustrated by producing structured artifacts for two distinct external hardware platforms (SimpleFOC and Quanser rotary inverted pendulums). No mathematical derivations, equations, fitted parameters, or predictions appear in the provided text. The workflow is positioned relative to existing requirements-driven and AI-assisted methods via standard citations, but no load-bearing step reduces to a self-citation, self-definition, or renaming of the authors' own prior results. The demonstration relies on independent hardware rather than quantities defined inside the paper, satisfying the criteria for a self-contained descriptive framework.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The framework rests on standard assumptions about design traceability and AI interpretability of specifications; no free parameters, invented entities, or ad-hoc axioms are introduced beyond domain conventions for requirements engineering.

axioms (1)
  • domain assumption Structured specifications can serve as an effective shared contract between humans and AI agents without substantial loss of design intent.
    Invoked in the positioning of Design-OS as the contract mechanism across all five stages.

pith-pipeline@v0.9.0 · 5553 in / 1187 out tokens · 30305 ms · 2026-05-15T07:04:11.290585+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

36 extracted references · 36 canonical work pages

  1. [1]

    When and how to use AI in the design process?

    Lee, M., Law, E., and Hoffman, R. R., 2024. “When and how to use AI in the design process?”.International Journal of Human– Computer Interaction,41(2), pp. 1569–1584

    work page 2024

  2. [2]

    Agentic large language models for conceptual systems engineering and design

    Massoudi, S., and Fuge, M., 2025. “Agentic large language models for conceptual systems engineering and design”. In International Design Engineering Technical Conferences and Computers and In- formation in Engineering Conference, V ol. 89237, American Society of Mechanical Engineers, p. V03BT03A045

    work page 2025

  3. [3]

    D., Shortell, T

    Walden, D. D., Shortell, T. M., Roedler, G. J., Delicado, B. A., Mornas, O., Ip, Y .-S., and David, E., 2023.Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 5th ed. Wiley, Hoboken, NJ

    work page 2023

  4. [4]

    Springer

    Pahl, G., Beitz, W., Feldhusen, J., and Grote, K.-H., 2007.Engineer- ing design: a systematic approach, 3rd ed. Springer

    work page 2007

  5. [5]

    Current development on using rotary inverted pendulum as a benchmark for testing linear and nonlinear control algorithms

    Hamza, M. F., Yap, H. J., Choudhury, I. A., Isa, A. I., Zimit, A. Y ., and Kumbasar, T., 2019. “Current development on using rotary inverted pendulum as a benchmark for testing linear and nonlinear control algorithms”.Mechanical Systems and Signal Processing, 116, pp. 347–369

    work page 2019

  6. [6]

    GitHub spec kit

    GitHub, 2025. GitHub spec kit. https://github.com/github/spec-kit. Accessed: 2026-02-01

    work page 2025

  7. [7]

    Specification-driven development: Spec Kit

    Microsoft, 2025. Specification-driven development: Spec Kit. https: //developer.microsoft.com/blog/spec-driven-development-spec-kit. Accessed: 2026-02-01

    work page 2025

  8. [8]

    The new V-model of VDI 2206 and its validation

    Gräßler, I., and Hentze, J., 2020. “The new V-model of VDI 2206 and its validation”.at–Automatisierungstechnik,68(5), pp. 312–324

    work page 2020

  9. [9]

    Stage-gate systems: a new tool for managing new products

    Cooper, R. G., 1990. “Stage-gate systems: a new tool for managing new products”.Business Horizons,33(3), pp. 44–54

    work page 1990

  10. [10]

    Requirements engineering: a roadmap

    Nuseibeh, B., and Easterbrook, S., 2000. “Requirements engineering: a roadmap”. In Proceedings of the Conference on the Future of Software Engineering, ACM, pp. 35–46

    work page 2000

  11. [11]

    Four dark corners of require- ments engineering

    Zave, P., and Jackson, M., 1997. “Four dark corners of require- ments engineering”.ACM Transactions on Software Engineering and Methodology (TOSEM),6(1), pp. 1–30

    work page 1997

  12. [12]

    An analysis of the require- ments traceability problem

    Gotel, O., and Finkelstein, A., 1994. “An analysis of the require- ments traceability problem”. In Proceedings of IEEE International Conference on Requirements Engineering, IEEE, pp. 94–101

    work page 1994

  13. [13]

    Toward reference models for requirements traceability

    Ramesh, B., and Jarke, M., 2001. “Toward reference models for requirements traceability”.IEEE Transactions on Software Engineer- ing,27(1), pp. 58–93

    work page 2001

  14. [14]

    IEEE Recommended Practice for Software Require- ments Specifications

    IEEE, 1998. “IEEE Recommended Practice for Software Require- ments Specifications”.IEEE Std 830-1998, pp. 1–40

    work page 1998

  15. [15]

    ISO/IEC/IEEE International Standard - Sys- tems and software engineering – Life cycle processes – Requirements engineering

    ISO/IEC/IEEE, 2018. “ISO/IEC/IEEE International Standard - Sys- tems and software engineering – Life cycle processes – Requirements engineering”.ISO/IEC/IEEE 29148:2018(E), pp. 1–104

    work page 2018

  16. [16]

    Easy approach to requirements syntax (EARS)

    Mavin, A., Wilkinson, P., Harwood, A., and Novak, M., 2009. “Easy approach to requirements syntax (EARS)”. In 2009 17th IEEE international requirements engineering conference, IEEE, pp. 317– 322

    work page 2009

  17. [17]

    B., 2026

    Piskala, D. B., 2026. Spec-driven development: from code to contract in the age of AI coding assistants. arXiv:2602.00180

    work page arXiv 2026

  18. [18]

    Design prototypes: a knowledge representation schema for design

    Gero, J. S., 1990. “Design prototypes: a knowledge representation schema for design”.AI Magazine,11(4), pp. 26–36

    work page 1990

  19. [19]

    MetaGPT: meta programming for a multi-agent collaborative framework

    Hong, S., Zheng, X., Chen, Y ., Cheng, J., Zhang, C., Wang, Z., Xu, Q., et al., 2024. “MetaGPT: meta programming for a multi-agent collaborative framework”. In International Conference on Learning Representations (ICLR)

    work page 2024

  20. [20]

    ChatDev: communicative agents for software development

    Qian, C., et al., 2024. “ChatDev: communicative agents for software development”. In Proceedings of the ACL, pp. 15174–15186

    work page 2024

  21. [21]

    A., D˛ abrowski, J., Alhoshan, W., Zhao, L., and Ferrari, A., 2025

    Zadenoori, M. A., D˛ abrowski, J., Alhoshan, W., Zhao, L., and Ferrari, A., 2025. Large language models for requirements engineering: a systematic review. arXiv:2509.11446

    work page arXiv 2025

  22. [22]

    Conceptual design generation using large language models

    Ma, K., Grandi, D., McComb, C., and Goucher-Lambert, K., 2023. “Conceptual design generation using large language models”. In Inter- national Design Engineering Technical Conferences and Computers and Information in Engineering Conference, V ol. 87349, American Society of Mechanical Engineers, p. V006T06A021

    work page 2023

  23. [23]

    Generative pre-trained transformers (GPT) for design concept generation: an exploration

    Zhu, Q., and Luo, J., 2022. “Generative pre-trained transformers (GPT) for design concept generation: an exploration”.Proceedings of the design society,2, pp. 1825–1834

    work page 2022

  24. [24]

    Inverted pendulum systems: rotary and arm- driven—a mechatronic system design case study

    Awtar, S., King, N., Allen, T., Bang, I., Hagan, M. D., Skidmore, D., and Craig, K., 2002. “Inverted pendulum systems: rotary and arm- driven—a mechatronic system design case study”. In Mechatronics, V ol. 12, pp. 357–370

    work page 2002

  25. [25]

    The inverted pendulum benchmark in nonlinear control theory: a survey

    Boubaker, O., 2013. “The inverted pendulum benchmark in nonlinear control theory: a survey”.International Journal of Advanced Robotic Systems,10(5)

    work page 2013

  26. [26]

    Control learning: present and future

    Dormido Bencomo, S., 2004. “Control learning: present and future”. Annual Reviews in Control,28(1), pp. 115–136

    work page 2004

  27. [27]

    A., and Chatterjee, S.,

    Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chatterjee, S.,

    work page

  28. [28]

    A design science research methodology for information systems research

    “A design science research methodology for information systems research”.Journal of Management Information Systems, 24(3), pp. 45–77

    work page

  29. [29]

    Swing-up control of inverted pendulum using pseudo-state feedback

    Furuta, K., Yamakita, M., and Kobayashi, S., 1992. “Swing-up control of inverted pendulum using pseudo-state feedback”.Pro- ceedings of the Institution of Mechanical Engineers, Part I,206(6), pp. 263–269

    work page 1992

  30. [30]

    Research papers

    Quanser, 2026. Research papers. Quanser Community

    work page 2026

  31. [31]

    Digital pendulum system 33-005-PCI

    Feedback Instruments, 2025. Digital pendulum system 33-005-PCI. Feedback Instruments (distributed by LD Didactic/Leybold)

    work page 2025

  32. [32]

    Reaction wheel inverted pendulum: Arduino SimpleFOC

    SimpleFOC Community, 2023. Reaction wheel inverted pendulum: Arduino SimpleFOC

    work page 2023

  33. [33]

    SimpleFOC: a field oriented control (FOC) library for controlling brushless direct current (BLDC) and stepper motors

    Skuric, A., Bank, H. S., Unger, R., Williams, O., and González- Reyes, D., 2022. “SimpleFOC: a field oriented control (FOC) library for controlling brushless direct current (BLDC) and stepper motors”. Journal of Open Source Software,7(74), p. 4232

    work page 2022

  34. [34]

    Design and implementation of a prototype pendu- lum platform for aerospace controls education

    Wright, Z., 2023. “Design and implementation of a prototype pendu- lum platform for aerospace controls education”. M.S. thesis, Califor- nia Polytechnic State University, San Luis Obispo, June

    work page 2023

  35. [35]

    S., Herber, D

    Bank, H. S., Herber, D. R., and Bradley, T. H., 2026. Design- OS: Specification-driven framework for engineering system design. https://github.com/bankh/design-os. Accessed: 2026-03-12

    work page 2026

  36. [36]

    On the dynamics of the 9 Furuta pendulum

    Cazzolato, B. S., and Prime, Z., 2011. “On the dynamics of the 9 Furuta pendulum”.Journal of Control Science and Engineering, 2011, p. 528341. A DESIGN-OS COMMANDS Table 7 lists theDesign-OScommands, organized by workflow stage. Each command is a structured Markdown prompt file that defines the stage’s process steps, expected inputs and outputs, and valid...

    work page 2011