PaperlayerView exact revision on arXiv

Source-linked AI summary

Engineering as Code: Bringing Software Engineering Methodology to Engineering Design

Song Difei

arXiv:2609.04216v1cs.SE

TL;DR

Physical engineering lacks machine-checkable representations that separate design intent from geometry, limiting fast deterministic verification and AI training feedback. The paper proposes EaC with ADL and ESA as a text-native design and verification toolchain. Across three samples, the prototype checked 69 rules in under 200ms, while violation injection achieved 100% detection with zero false positives.

  • Problem

    Physical engineering uses geometry-centric CAD/BIM representations that couple design intent with geometric realization and hinder machine-checkable verification.

  • Method

    EaC separates textual design intent in ADL from geometry, using ESA to perform layered semantic checking as part of a software-engineering toolchain.

  • Results

    100% detection rate with zero false positives was achieved in violation-injection experiments, while three samples passed 69 total rules with latency under 200ms.

  • Takeaways & Limitations

    EaC provides a proposed source-of-truth representation and design-time quality-gating framework for machine-checkable engineering design.

  • Takeaways & Limitations

    Current PLL geometry solving uses principal-axis approximation and does not yet support 1D continuous-path topologies such as piping or cabling.

Abstract

from arXiv · show

Large language models have made significant progress in verifiable domains such as code generation and chip design, yet remain limited on engineering design tasks in fields like architecture, mechanical engineering, and HVAC. This paper argues the root cause is not model capability but the absence of a "Design as Code" computable foundation: design representations that can be consumed, verified, and versioned by machines. Existing CAD/BIM systems couple design logic with geometry, causing quality assurance to drift downstream; Automated Compliance Checking (ACC) suffers from geometric false positives and naming-dependent model reconstruction overhead. We propose the Engineering as Code (EaC) paradigm: expressing engineering design as text-native declarative language with automated rule engines, version control, and package management as quality gates. Core contributions: (1) the Information Representation Hypothesis, arguing the engineering AI bottleneck stems from missing computable design representations rather than model capability; (2) ADL (Assembly Definition Language) with Part as atom, organized into three orthogonal sub-languages -- PDL (Part Definition), PML (Part Mating), and PLL (Part Layout); (3) ESA (Engineering Static Analysis), shifting compliance checking from downstream review to design-time, operating on semantic categories (Family types, Mate relations) rather than geometry, eliminating false positives and naming dependencies. A prototype validates ADL expressiveness and ESA detection across three cross-domain samples (telecom rack expansion, modular datacenter, mechanical keyboard), checking 69 rules in under 200ms. A controlled violation injection experiment achieves 100% detection rate with zero false positives. The SD-HWE-Bench benchmark design is complete as an empirical testbed for the hypothesis.

1 Introduction

Software engineering advances AI by providing structured representations, deterministic checks, and fast feedback, whereas physical engineering lacks an equivalent machine-checkable design foundation. The paper proposes EaC, ADL, and ESA to establish that infrastructure for engineering design.

  • Software engineering artifacts support inspection, versioning, static analysis, and deterministic feedback that reinforcement learning with verifiable rewards can exploit.
  • Physical engineering artifacts remain geometry-centric and tool-coupled, without separating design intent from geometric instantiation.
  • Geometric ACC produces false positives and depends on naming conventions, limiting reliable design-time verification.
  • The paper argues that missing representation infrastructure, rather than insufficient algorithmic capability, is the central bottleneck for engineering AI.
  • EaC contributes ADL as a text-native representation and ESA as a layered semantic rule checker integrated with software-engineering workflows.
  • ADL targets engineering designers and AI agents by balancing human readability with machine verifiability, extending domain-specific-language practice to physical engineering.

2 Background and Motivation

The paper links AI progress in code, mathematics, and chip design to structured representations with fast deterministic checking, then identifies representation-layer deficiencies that prevent physical engineering from joining that pattern. EaC is presented as the missing upstream, machine-checkable design representation.

  • Across code, mathematics, and chip design, structured representations enable deterministic checking and fast feedback that support RLVR.
  • Physical engineering lacks this chain because CAD and BIM couple functional identity, geometric realization, and tool-specific state.
  • Geometry-centered representations lose functional relationships, delay feedback until completed designs, and provide no millisecond-scale training signal.
  • Geometric clash detection generates false positives because models lack semantic declarations distinguishing intentional penetrations from genuine layout errors.
  • Naming-dependent ACC requires project-specific remodeling before checking, adding manual labor, errors, and nonreproducible evaluation conditions.
  • The paper identifies an upstream, text-native, machine-checkable representation as the missing foundation for both generative agents and human engineers.

3 The Engineering as Code Approach

EaC treats textual design declarations as the source of truth and surrounds them with version control, static analysis, and automated verification. Its Information Representation Hypothesis connects this architecture to the need for fast, deterministic feedback in engineering AI.

  • EaC defines a structured textual design declaration as the single source of truth for a physical engineering system.
  • ADL, ESA, and the Information Representation Hypothesis form EaC’s representation, verification, and theoretical layers.
  • The hypothesis attributes physical-engineering AI lag primarily to absent machine-checkable representations rather than insufficient model capability or physics complexity.
  • Code, mathematics, and chip design illustrate a common structure in which decomposable representations make correctness feedback computable.
  • Physical engineering currently lacks both a representation structured for checking and sufficiently fast downstream verification.
  • SD-HWE-Bench is designed to test predictions about ESA feedback and layered diagnostics, while the long-term downstream-error prediction remains an empirical goal.
  • EaC’s framework combines a text-native DSL, layered static analysis, and toolchain integration, with proposed applicability beyond physical engineering.

4 ADL: Assembly Definition Language

ADL is a text-native declarative representation that separates part identity, relationships, and spatial placement into orthogonal layers. Its Part abstraction captures semantic engineering entities while keeping layout independent from reusable part definitions.

  • ADL expresses design intent in YAML and separates what exists, how parts couple, and where they are placed.
  • Its goals are text-native authoring, deterministic agent-oriented validation, and orthogonality among identity, relationships, and space.
  • A Part is ADL’s atomic engineering unit, combining family, model, instance, typed interfaces, and optional hidden geometry.
  • Part semantics include typed schemas, encapsulated geometry, and explicit relationships such as mating and connection roles.
  • PDL organizes parts as Family, Model, and Instance, with family constraints, model defaults, and deployable overrides.
  • Instance files exclude layout information, allowing the same device definition to be reused across alternative positions and designs.

4.4 PML: Part Mating Language

PML defines relationships between Parts through distinct Mate and Connection categories, separating feasibility constraints from functional topology. This separation enables independent validation of mechanical or electrical fit and signal, energy, or material flow.

  • PML distinguishes Mate relationships from Connection relationships between Parts.Mate captures how Parts fit or work together, while Connection captures flow between interfaces.
  • Mate expresses design coupling and is validated by the engine at load time.Registered Mate types include sfp28-cage, power-iec-c14-c13, and lc-connector.
  • Connection represents signal, energy, or material flow between two interfaces as a first-class Instance.The representation records source and destination ports together with a cable type.
  • The Mate/Connection split separates mechanical or electrical feasibility from functional topology correctness.CAD/BIM systems often merge these dimensions, preventing validation of one without involving the other.

4.5 PLL: Part Layout Language

PLL removes remaining layout degrees of freedom after mating constraints while keeping layout data separate from definitions and relationships. Its current solver uses principal-axis approximations and does not yet support one-dimensional continuous-path topologies.

  • PLL eliminates geometric degrees of freedom retained by mates and free Parts in an assembly.It completes the pose and state information needed to determine concrete layouts.
  • For mated Parts, PLL completes continuous and discrete degrees of freedom after the PML mating solver determines the primary pose.It assigns values for translation, rotation, screw, and states such as normal, reverse, or unplugged.
  • PLL separates layout data from PDL and PML files so layout changes do not alter definitions or mating relationships.This preserves the orthogonality of the three ADL sub-languages.
  • The current PLL solver uses principal-axis approximation and excludes one-dimensional continuous-path topologies such as piping and cabling.These capabilities are deferred to future solver precision enhancements and external CAE tool handling.

4.6 Orthogonality

ADL makes PDL, PML, and PLL orthogonal through separate files and namespaces, enabling phased validation, parallel editing, and semantically interpretable changes.

  • PDL, PML, and PLL occupy independent files and namespaces, so changes in one design dimension do not rewrite another.PDL uses instances/ and models/, PML uses mates/, and PLL uses layouts/.
  • Incremental validation lets agents pass PDL checks before adding PML constraints and PLL spatial rules.The workflow provides phased error feedback analogous to a compiler.
  • Separate design dimensions allow device, layout, and mechanical engineers to edit concurrently, with conflicts limited to shared decisions.Example files span instances/SRV-01.yaml, layouts/layout.yaml, and a rack-mount mate file.
  • Semantic diffs identify whether a change affects identity, mating, or position.A position_u change is a layout change, while changing tdp_w in a Part instance is an electrical change.

4.7 Comparison with SysML v2 and BIM/IFC

ADL, SysML v2, and BIM/IFC all formalize engineering systems but differ in source-of-truth form, collaboration units, and target users. ADL prioritizes text-native, agent-human collaboration and treats CAD/BIM as downstream consumers.

  • ADL, SysML v2, and BIM/IFC differ in assumptions about source-of-truth form, collaboration units, and target users.
  • Table 2 compares ADL with SysML v2 and BIM/IFC across source-of-truth, versioning, and verification dimensions.
  • SysML v2 and BIM primarily serve human engineers, while their repositories or central files are difficult to diff, branch, and automatically verify.IFC additionally couples identity, geometry, and relationships in a graph with multiple equivalent serializations.
  • ADL treats text as the sole source of truth and makes verification first-class, while CAD and BIM become downstream consumers for visualization, clash detection, and manufacturing.

4.8 Core Syntax Summary

ADL defines a project grammar for model, instance, mating, and layout files, with semantic constraints supplementing the core syntax. Its constructs represent families, models, interfaces, mating relations, constraints, and alternative layout poses.

  • A project consists of piki.toml plus zero or more model, instance, mate, or layout files.
  • Part definitions can identify either a family or model, include fields, and optionally declare interfaces with types, directions, and local transforms.
  • Mating relations connect parent and child references and may specify maps, field constraints, and interface pairings.
  • Layout entries identify instances and use exactly one absolute, relative, or grid pose.
  • Semantic validation requires that instance files exclude layout fields and that references resolve to existing interfaces.

5 ESA: Engineering Static Analysis

ESA shifts compliance checking from downstream geometric inspection to deterministic, design-time analysis of ADL declarations. It uses semantic categories, explicit relationships, layered rules, and CI-compatible diagnostics to reduce naming dependence and catch engineering violations early.

  • Purpose: ESA consumes ADL declarations and checks deterministic rules before design submission, moving compliance review from downstream inspection to upstream gating.Its inputs are design declarations rather than completed geometry.
  • Limitations of ACC: Traditional ACC loses design logic in geometry, delays feedback until multi-discipline integration, and cannot provide millisecond reward signals during generation.Geometric clash detection also creates false positives, while naming conventions impose costly model rework.
  • Semantic checking: ESA operates on semantic Part Families and explicit Mate relationships, allowing rules to identify intended interactions and avoid naming-pattern dependencies.Layered L0–L4 checking separates syntax, reference integrity, and business-rule diagnostics.
  • Rule authoring: The rack power-budget example shows ESA iterating over PDUFamily instances and connected loads without per-project naming customization.Diagnostics identify the specific PDU output and over-limit loads.
  • Scope and workflow: ESA is deterministic, low-cost, and suitable for pre-commit or CI gating, but it does not replace CAE/CFD or human review.Its role is to intercept deterministic front-end errors so expensive validation can focus on issues requiring expert judgment.
  • Rule hierarchy: The prototype implements L2–L4a telecom-rack rules, including interface compatibility, power capacity, U-position conflicts, rack capacity, and spatial checks.Rules are registered with decorators and can be enabled by design phase.
  • Diagnostics: The prototype completes telecom-rack checking in under 200ms, reports one warning and 29 passes, and emits structured diagnostics for CI dashboards and other tools.A maintenance-aisle spacing violation is reported as a warning, while outputs are consumable by terminals, IDEs, and PR bots.

6 Evaluation

The evaluation tests ADL expressiveness, ESA verification, cross-domain portability, and reproducible violation detection. Three samples pass layered checks, while the benchmark for natural-language-to-ADL generation remains deferred.

  • Evaluation design: The evaluation measures ADL expressiveness, check latency, rule coverage, detection accuracy, and downstream deliverable generation on piki samples.Measurements use a laptop-class machine with a hot cache, reporting median latency across five runs.
  • Sample projects: The telecom rack sample passes all L2–L4a rules with 1 warning, delivers sub-200ms feedback, and generates 10 downstream artifacts.The warning concerns aisle width below the required 600mm between RACK-A01 and RACK-A02.
  • Sample projects: The modular datacenter sample records 13 passes and 0 errors after fixes to empty-string validation, transform parsing, and cooler positioning.The result supports PLL relative-skeleton modeling and container-level coordinate chains.
  • Sample projects: The mechanical keyboard sample records 27 passes and 0 errors after correcting the LAYOUT-001 empty-string defect in its continuous 2D grid layout.Its skeleton-based assembly uses parent-transform chains for the case, PCB, plate, battery, switches, keycaps, and stabilizers.
  • Violation-injection experiment: 15/15 injected violations are detected with zero false positives, while all 30 rules complete within 200ms on a laptop with a hot cache.ESA checks semantic categories such as Family types and Mate relations rather than geometry.
  • Limitations and future evaluation: The evaluation does not quantitatively compare ESA with ACC and does not test agents generating ADL from natural-language requirements.SD-HWE-Bench is designed for the latter evaluation and is deferred to a companion paper.
  • Sample projects: All three samples pass L2–L4a checks, supporting cross-domain validation of ADL expressiveness and ESA detection capability.The samples cover telecom racks, modular datacenter infrastructure, and mechanical keyboard assembly.

7 Related Work

Related work positions EaC at the intersection of RLVR, DSLs, static analysis, engineering benchmarks, and Infrastructure as Code. Its distinguishing move is to make text-based computable engineering descriptions the source of truth, with CAD/CAE as downstream consumers.

  • RLVR and engineering AI: EaC extends RLVR’s structured-verification pattern to physical engineering by addressing the missing computable representation needed before verifiable rewards can operate.The paper frames existing RLVR work as establishing the latter half of the causal chain and EaC as addressing its representational foundation.
  • Engineering benchmarks: Existing engineering benchmarks assess reviewing or CAD/BIM-based tasks, but do not require a Design as Code intermediate representation for design generation.AEC-Bench reviews human-created drawings, while EngDesign evaluates tasks within existing CAD/BIM workflows.
  • Engineering benchmarks: Circuit-design benchmarks benefit from a Circuit as Code foundation, providing an upper-bound reference for SD-HWE-Bench once traditional engineering gains a comparable foundation.The cited EDA benchmarks exhibit high RLVR compatibility, while Rule2DRC supports executable verification.
  • Declarative modeling and formal methods: ADL differs from SysML v2 by targeting agent–human textual collaboration with YAML as the source of truth and layered verification rather than repository-centered GUI modeling.SysML v2 provides part/occurrence separation, connection relationships, and repository-based version control, but follows a different modeling methodology.
  • Declarative modeling and formal methods: ADL inverts BIM/IFC’s arrangement by making text the source of truth and treating CAD/BIM as downstream consumers, improving the basis for line-level version control.The comparison identifies IFC’s coupling of identity, geometry, and relationships as making line-level version control difficult.
  • AI4E implementation paths: Unlike CUA and CAD-MCP, EaC places computable engineering descriptions at the center and makes CAD/CAE tools downstream consumers and renderers.CUA operates CAD through GUIs, while CAD-MCP wraps structured interfaces but remains tied to proprietary CAD kernels.

8 Conclusion

The paper proposes Engineering as Code as a text-native foundation for expressing engineering intent, enforcing rules at design time, and integrating software-engineering workflows. Its prototype supports ADL and ESA across three engineering samples, while broader validation and RLVR testing remain future work.

  • EaC makes textual declarations the source of truth, with rule engines, version control, and package management forming quality gates for engineering design.
  • The paper’s three contributions are ADL, ESA, and the Information Representation Hypothesis.ADL defines a text-native assembly language; ESA moves compliance checking to design generation; the hypothesis attributes the engineering AI bottleneck to missing computable design representations.
  • ADL uses Part as its atomic unit and separates part definition, mating, and layout into the orthogonal PDL, PML, and PLL sub-languages.PLL supports parameterized degrees-of-freedom completion, mate constraint solving, and assembly hierarchy management.
  • ESA checks design declarations at the semantic-category level instead of relying on geometrically instantiated artifacts, avoiding geometric collision false positives and naming-dependent reconstruction.
  • The piki prototype passed 69 total rules in <200ms across telecom rack, modular data center, and mechanical keyboard samples, with 100% violation detection and zero false positives.The SD-HWE-Bench design is complete as an empirical platform for testing the Information Representation Hypothesis.
  • Future work includes improving continuous-DOF and path-topology solving, developing package and assembly registries, expanding domain validation, and conducting RLVR experiments.
Loading 2609.04216v1…