Structured Spec-Driven Engineering (SSDE)

• SSDE is a specification-centered engineering paradigm that uses structured artifacts to drive design, planning, implementation, and verification across various domains.
• It employs diverse, domain-specific representations—like Gherkin scenarios, OpenAPI contracts, and TLA⁺ models—to reduce ambiguity and enhance traceability.
• SSDE integrates human–AI collaboration within staged workflows, ensuring rigorous evolution of specifications and measurable improvements in system verification.

Structured Spec-Driven Engineering (SSDE) denotes a paradigm in which structured specifications are the primary artifacts guiding design, planning, implementation, verification, and maintenance, while code, models, tests, and documentation are generated from or checked against those specifications (Feng et al., 4 May 2026, Piskala, 30 Jan 2026). In recent work, SSDE spans spec-first, spec-anchored, and spec-as-source regimes; treats specifications as a shared contract between humans and AI agents; and extends from software repositories to physical engineering systems, distributed systems, UI design, autonomous-agent security evaluation, and automated scientific analysis (Bank et al., 20 Mar 2026, Piskala, 30 Jan 2026).

1. Definition, scope, and intellectual context

SSDE is best understood as a family of specification-centered methods rather than a single formalism. Its common premise is that ambiguity, weak traceability, and implementation-first workflows are structural causes of engineering failure. The specification therefore becomes the authoritative description of intended behavior, constraints, interfaces, verification criteria, and, in stronger forms, the only artifact humans edit directly (Piskala, 30 Jan 2026, Feng et al., 4 May 2026). Within this family, recent work distinguishes three levels of authority: spec-first, in which a specification guides initial implementation; spec-anchored, in which specification and code are maintained together; and spec-as-source, in which code is generated from the specification and should not be manually modified (Piskala, 30 Jan 2026).

The scope of SSDE is no longer software-only. Design-OS explicitly positions a lightweight, specification-driven workflow for physical engineering system design and treats specifications as the “binding contract” between conceptual intent and implementation across mechanical, electrical, and software domains (Bank et al., 20 Mar 2026). Automotive MBSE work similarly makes stakeholder concerns, validation concerns, test scenarios, and system requirements parts of one central model from which required specifications are derived automatically (Wiecher et al., 2022). This suggests that SSDE is better viewed as a cross-domain methodology for organizing artifact evolution, not merely as an LLM prompting technique.

A plausible lineage includes earlier formal-specification reuse in model-based testing, operational natural-language specifications, and structure-preserving model transformations. “Using Formal Specifications to Support Model Based Testing ASDSpec” reused ASD interface models to generate Spec Explorer artifacts for dynamic testing (Meer et al., 2014). “Towards operational natural language” turned structured-natural-language specifications into runnable programs that yield multiple consistent-by-construction views (Naumchev, 2017). “Structure Preserving Transformations for Practical Model-based Systems Engineering” formalized semantic structures, interpretation maps, and structure-preserving transformations for model synchronization at the system level (Ji et al., 2022). Recent SSDE work generalizes these ideas into AI-assisted, repository-scale, and cross-domain settings.

2. Specification artifacts and representational forms

SSDE does not depend on a single notation. Recent systems employ a broad range of structured artifacts, each chosen for a specific role in the engineering loop. Software-oriented SSDE uses Gherkin scenarios, OpenAPI contracts, domain models in Umple or Ecore, signature models, and staged markdown artifacts such as SPEC.md, PLAN.md, and TASKS.md (Feng et al., 4 May 2026, Taghavi et al., 7 Apr 2026). Physical-system workflows use requirements tables, domain decompositions, interface equations, and stage documents such as mission.md, roadmap.md, and tech-stack.md (Bank et al., 20 Mar 2026). Data-analysis workflows use command markdown files such as @raw-data-analysis.md, @preprocess.md, and @research-plan.md, together with context documents in docs/ that function as persistent research memory (Chen et al., 13 Oct 2025).

Several systems introduce domain-specific intermediate representations. SpecifyUI defines SPEC as a structured, parameterized, hierarchical intermediate representation with a global specification $\mathcal{G} = \langle L, C, S, U \rangle$ and a page-composition hierarchy, enabling global, regional, and component-level edits through structured edit instructions of the form $\langle operation, path, value \rangle$ (Chen et al., 9 Sep 2025). Sedeve-Kit uses TLA${^+}$ specifications and invariants as the starting artifact for distributed systems, then derives traces and test cases from model-checked state graphs (Guo et al., 15 Sep 2025). SeClaw begins from structured risk specifications that encode risk type, risk source, agent role, user-facing task, unsafe behavior, and safety constraints, then synthesizes executable tasks and trajectory-aware evaluators from them (Cheng et al., 1 Jun 2026).

Requirements engineering work shows that SSDE often depends on controlled natural language or patternized forms rather than full formal logic. Specogramming treats a modern object-oriented IDE as a word processor and turns structured-natural-language specifications into executable programs that generate documentation and seamless requirements (Naumchev, 2017). Pattern-based domain-specific requirements engineering for UAV flight controllers uses Domain-Specific Requirements composed of figures and tables, with reusable patterns such as Take-off, Hover, Landing, and Trajectory Following DSRs, plus explicit parameter ranges and constraints (Chuprina et al., 2024). This suggests that SSDE representations are typically “formal-ish”: structured enough for automation, yet still legible to domain experts.

3. Process models and staged specification evolution

Across implementations, SSDE is staged rather than monolithic. Design-OS organizes engineering design into five stages: concept definition, literature survey, conceptual design, requirements definition, and design definition (Bank et al., 20 Mar 2026). The workflow enforces a specification-before-implementation discipline: no design definition until requirements are fixed, and no requirements until conceptual design is fixed. In the automotive MBSE methodology, 11 modeling activities are grouped into three method blocks—problem space, validation system, and product—and the process is explicitly iterative and non-linear (Wiecher et al., 2022). Spec Kit Agents implements the software workflow as a state machine over Specify → Plan → Tasks → Implement, with discovery and validation hooks at phase boundaries (Taghavi et al., 7 Apr 2026).

Other systems instantiate the same principle in different domains. ARIA uses a document-centric workflow spanning commands, context, code, data, orchestration, and AI module layers; execution order is recommended rather than enforced, but semantic dependencies between documents, code, and data are explicit (Chen et al., 13 Oct 2025). SeClaw uses a three-stage pipeline of task prototype synthesis, task instantiation, and trajectory-based validation with iterative refinement (Cheng et al., 1 Jun 2026). The Kitchen Loop defines six phases—Backlog, Ideation, Triage, Execution, Polishing, and Regression—and applies them continuously to a self-evolving codebase (Roy, 26 Mar 2026).

The significance of these workflows lies in how they force specification evolution to be visible. Design-OS treats literature grounding, feasibility, requirements, and implementation planning as first-class artifacts rather than tacit background knowledge (Bank et al., 20 Mar 2026). Automotive MBSE similarly insists that validation concerns, validation goals, test scenarios, and test environments be modeled, not improvised (Wiecher et al., 2022). In software repositories, phase-level grounding in actual repository evidence reduces hallucinated APIs and architectural violations, while explicit intermediate artifacts create an audit trail that is absent in one-shot prompting (Taghavi et al., 7 Apr 2026). SSDE therefore replaces a single undifferentiated “generate solution” step with a sequence of transformations over named artifacts.

4. Traceability, verification, and auditability

A defining property of SSDE is that traceability is not merely desirable; it is encoded into the method. In Design-OS, traceability is maintained by linking requirement IDs to design parameters and verification steps, and REQ-12 is itself “Traceability table: REQ → param → verif.” (Bank et al., 20 Mar 2026). The paper’s control-systems case makes this concrete: performance requirements such as damping ratio and natural frequency flow into pole placement, feedback gain $K$, electrical behavior, and mechanical motion, with simulation used to check each requirement numerically. In the automotive MBSE methodology, the central system model preserves links from stakeholder requirement to system requirement to test case to test result, while derived views expose missing links as gaps in coverage (Wiecher et al., 2022).

Distributed-systems SSDE strengthens this further by coupling specifications to deterministic execution. Sedeve-Kit instruments TLC to persist model states, derives traces with TraceGen, and uses D-Player and Action Anchor Macros to force the implementation to follow specification traces while checking expected states after each action (Guo et al., 15 Sep 2025). ASDSpec earlier demonstrated the same architectural idea in a different form: ASD interface models are transformed into Spec Explorer models and test scripts so that the same formal specification drives both static verification and dynamic testing (Meer et al., 2014). These systems make traceability operational rather than documentary.

Recent AI-oriented systems add explicit drift control. The Spec Growth Engine builds an Intent Graph from SPEC.md and ARCHITECTURE.md, an Evidence Graph from static code analysis, and a drift gate that blocks merges on orphan code, undeclared dependencies, dependency bypasses of contracts, or missing dependency contracts (Grabowski, 25 Jun 2026). Citation-discipline work sharpens the trade-off at code level: mandatory per-line citations with hierarchical REQ-XXX.Y.Z identifiers enable automated hallucination detection with TDR 86.4% for Claude and 88.0% for GLM-5-turbo, with FPR 0% across both studies, whereas uncited and artifact-level alternatives yield 0% automated detection (Panda, 28 Jun 2026). The same study also shows that citation annotations reduce output determinism, establishing a replicated trade-off between determinism and verifiability.

Execution-based evaluation extends traceability beyond static artifacts. SeClaw represents each task instance by a configuration and trajectory, $r_i = J(C_i, T_i) \in \{0,1\}$, and aggregates outcomes through coverage and attack metrics over predefined security targets (Cheng et al., 1 Jun 2026). The Kitchen Loop similarly uses “Unbeatable Tests,” a regression oracle, blocked-combo registries, and pause gates to ensure that autonomous evolution remains bounded by observable evidence rather than local pass/fail artifacts (Roy, 26 Mar 2026). In SSDE, auditability therefore ranges from requirement tables and view generation to trajectory logs, deterministic replay, and CI-enforced drift gates.

5. Human–AI collaboration and agent orchestration

SSDE consistently treats specifications as the shared interface through which humans and AI agents cooperate. Design-OS explicitly assigns humans responsibility for intent, priorities, feasibility decisions, literature verification, and spec acceptance, while AI agents act as stage executors governed by commands such as /plan-project, /literature-search, /spec, and /generate-simulation (Bank et al., 20 Mar 2026). Spec Kit Agents uses role separation between a Product Manager agent and a Developer agent, with an orchestrator supplying artifacts and hook outputs as context (Taghavi et al., 7 Apr 2026). ARIA frames the same arrangement as document-centric human-in-the-loop analysis: the AI module proposes, but the researcher disposes (Chen et al., 13 Oct 2025).

Two recurring SSDE mechanisms are context control and structured editability. The Spec Growth Engine introduces a Spine context assembler that scopes an agent’s bundle to root invariants, the ownership path, the node’s own spec and code, and one-hop dependency contracts, specifically to address context explosion and silent spec–code drift (Grabowski, 25 Jun 2026). SpecifyUI offers an analogous idea in design space: all iteration occurs on the SPEC layer, not by editing generated code directly, and the hierarchical representation permits targeted global, regional, or component-level changes without destabilizing the rest of the artifact (Chen et al., 9 Sep 2025). This suggests that SSDE externalizes intent into stable artifacts precisely to make AI behavior local, auditable, and reversible.

Quality control is also structured as multi-agent or multi-stage checking. SeClaw separates synthesis, quality checking, instantiation, and validation, with explicit quality-control agents ensuring prototype fidelity and evaluability (Cheng et al., 1 Jun 2026). The Kitchen Loop uses independent reviewers, sealed UAT cards, and a fresh evaluator model to prevent the same agent from both implementing and weakening the oracle (Roy, 26 Mar 2026). Across these systems, human judgment is not removed; it is relocated to boundary-setting, acceptance, and exception handling. The recurring lesson is that SSDE does not simply “add AI” to a workflow. It gives AI bounded roles inside a specification-governed process.

6. Representative domains and empirical instantiations

The breadth of current SSDE work is visible in the diversity of domains, artifacts, and measured outcomes.

Domain	Representative instantiation	Core spec artifacts
Physical engineering	Design-OS	five-stage workflow, requirements tables
Automotive systems	MBSE validation-focused method	stakeholder concerns, validation goals, test scenarios
Distributed systems	Sedeve-Kit	TLA${^+}$ specs, traces, invariants
UI design	SpecifyUI	SPEC hierarchical IR
Autonomous-agent security	SeClaw	structured risk specifications, task.yaml
Repository-scale software	Spec Kit Agents / Spec Growth Engine	SPEC.md, PLAN.md, TASKS.md, drift graphs
Scientific data analysis	ARIA	markdown commands, context documents
Self-evolving software	Kitchen Loop	specification surface, coverage matrix, unbeatable tests

Empirical results indicate that structured specifications affect both output quality and verification. Design-OS demonstrates that the same requirements set can govern two fundamentally different control-system platforms and reports simulation passes for requirements such as $\zeta = 0.7$, $\omega_n = 4\ \mathrm{rad/s}$, $|\alpha| < 15^\circ$, and $|V_m| < 10\,\mathrm{V}$ in its worked case (Bank et al., 20 Mar 2026). In automotive MBSE, all 67 stakeholder requirements were linked to application scenarios, and 57 functional stakeholder requirements led to 111 generated test cases (Wiecher et al., 2022). Sedeve-Kit reports a 3038-SLOC TLA$\langle operation, path, value \rangle$0 Raft specification, contrasting it with a much larger Coq specification-and-proof burden in Verdi, and uses exhaustive trace generation and deterministic replay as its practical verification strategy (Guo et al., 15 Sep 2025).

Human–AI co-creation settings show similar gains. SpecifyUI reports that Integrated SPEC achieves MSE 40.9930, CLIP 0.8871, and SSIM 0.854, outperforming the best prompt baseline, and in a study with 16 professional designers it reduced typing effort from about 1442 characters to about 386 characters while improving perceived intent alignment and controllability (Chen et al., 9 Sep 2025). Spec Kit Agents reports that context-grounding hooks improve judged quality by +0.15 on a 1–5 composite score, with $\langle operation, path, value \rangle$1, while maintaining 99.7–100 percent repository-level test compatibility, and reaches 58.2 percent Pass@1 on SWE-bench Lite with augmentation hooks (Taghavi et al., 7 Apr 2026). “LLM-Assisted Repository-Level Generation with Structured Spec-Driven Engineering” finds that adding domain or signature models substantially improves repository-level controller generation over natural-language-only baselines, and that signature models outperform raw domain models by +7.82% mean TPR with lower variance (Feng et al., 4 May 2026).

Security- and autonomy-oriented systems underscore the value of application-specific enrichment. The security knowledge transition benchmark evaluates backend generation under three conditions—baseline, ASVS-conditioned, and Multilayer Security Model conditioning—and reports that modal failures on a hidden 221-test suite drop from 50 to 42 to 36, with especially strong improvements in application-specific categories such as business logic and admin safety (Grynets et al., 29 May 2026). The Kitchen Loop reports 285+ iterations, 1,094+ merged pull requests, and zero regressions detected by its regression oracle, while also documenting emergent self-correction chains, autonomous infrastructure healing, and monotonically improving quality gates (Roy, 26 Mar 2026). These results do not imply that SSDE guarantees correctness, but they do show that structured specifications can measurably reshape both generation quality and the observability of failure.

7. Limitations, trade-offs, and future directions

SSDE does not eliminate the classical problems of engineering; it redistributes them. The most persistent limitation is specification quality itself. The kitchen-loop and security-transition work both assume that the relevant capability surface can be enumerated, enriched, and tied to verification (Roy, 26 Mar 2026, Grynets et al., 29 May 2026). Design-OS shows that human checkpoints remain critical for literature verification, feasibility go/no-go decisions, and final spec acceptance, because models can hallucinate references, skip steps, or invent extra requirement IDs (Bank et al., 20 Mar 2026). Automotive MBSE reports that the overhead may be high for small projects even though the benefits are significant for larger and more complex ones (Wiecher et al., 2022).

A second limitation is that increased structure does not improve every property simultaneously. The citation-discipline study shows a consistent cross-model trade-off: cited traceability reduces determinism while enabling automated hallucination detection (Panda, 28 Jun 2026). The Spec Growth Engine addresses context explosion and silent spec–code drift through machine-readable graphs and CI-enforced gates, but this introduces governance overhead and depends on static dependency discovery (Grabowski, 25 Jun 2026). Spec-as-source approaches eliminate certain forms of drift by construction, yet (Piskala, 30 Jan 2026) is explicit that they are practical mainly when code generation is viable and tooling is mature (Piskala, 30 Jan 2026). Sedeve-Kit similarly notes that correctness guarantees hold only within the design space of the specification and that applying the method to legacy systems requires adapter layers and instrumentation (Guo et al., 15 Sep 2025).

Future directions across the literature point toward stronger formalization, broader modality support, and richer integration between specification and verification. Design-OS calls for applications beyond the inverted pendulum and more advanced automation of requirement verification (Bank et al., 20 Mar 2026). ARIA proposes a domain-specific orchestration language that compiles natural-language specifications into explicit dependency graphs (Chen et al., 13 Oct 2025). SeClaw points to broader agent execution harnesses and richer trajectory semantics (Cheng et al., 1 Jun 2026). Structure-preserving MBSE work identifies synchronization across different model types, such as UML/SysML and fault trees, as a next step (Ji et al., 2022). This suggests that SSDE is moving toward a layered architecture in which controlled natural language, typed schemas, formal models, generated tests, and runtime evidence are not competing options but interoperable levels of one specification-centered engineering stack.