Embedded Files
Every engineering design rests on more than geometry. Requirements, assumptions, load cases, trade studies, allowables and test evidence explain why a part looks the way it does. In most projects that knowledge is spread across spreadsheets, CAD files, reports and the heads of a few people.
That was tolerable while humans did all the work. It breaks down once AI agents start proposing concepts, sizing members or generating CAD. An agent that can't see which requirement a dimension serves, or whether a result has been checked, produces output nobody can trust.
The Design Intent Graph is my attempt to fix this. It is an open-source Python library that stores design intent as a typed, machine-checkable graph. This article explains what the ontology is and how it helps engineers.
Concluding, I tried the logic on the example of a 3D-printed bridge that a team of agents designed end to end.
Latest Update: 2026-10-17
Contents & Overview
Contents & Overview
Description of the Ontology
Description of the Ontology
The Design Intent Graph is an ontology for engineering design: a fixed vocabulary of element types, the relations allowed between them, and rules that check the result. It is written in Python and stored as plain YAML and JSON, so both people and AI agents can read and write it.
It has three layers, each answering a different question.
1. The calculation graph: where does each number come from? Every value is a node produced by a versioned rule with a declared source. A value based on an assumption is marked Provisional, and the flag spreads to every number computed from it. A result can't quietly lose its weak foundation.
2. The system model: is the design verified? This is a model in the style of model-based systems engineering (MBSE). It holds needs, requirements, parts, verification cases, assumptions and evidence. Typed links connect them: derive, refine, satisfy, verify, allocate and trace.
The key idea is that a requirement's status is derived, never asserted. A requirement counts as SATISFIED only when all of these hold:
a human approved it, pinned to a hash of its content
a part claims to satisfy it
every verification case is approved and has current, passing evidence
no assumption it depends on is still open, and all derived requirements are satisfied
Evidence is bound to hashes of the requirement, the case and the tool. Change the design and the old evidence goes stale automatically.
3. The process layer: what is missing, and who should do it? Stages such as requirements, concepts, allowables, sizing, analysis, verification and test have dependencies and exit criteria. Seventeen completeness and consistency rules turn gaps into open items, for example a failure mode with no analysis or a CAD mass that disagrees with the sizing mass.
The process layer adds engineering element types too: Statement, DesignRule, Concept, TradeStudy, LoadCase, FailureMode, OptimizationSpec, Allowable, Credibility, Review and ConsistencyCheck. As the case study shows, this layer exists because the bridge project showed it was missing.
Agents work through the process layer.
Only the engineer can approve requirements and declare tools in the system model.
How it helps engineers
How it helps engineers
The ontology does not design anything itself. It records design work in a form that can be checked, and it refuses to call something finished before it is. In practice that gives an engineer five things.
Benefit & What the ontology does
Benefit & What the ontology does
Traceability: Every requirement traces to a need and a stakeholder statement; every number traces to a rule, a source or a named assumption
Honest status: Status per requirement is computed as SATISFIED, NOT_SATISFIED, OPEN or BLOCKED, with margins from measured value, unit and uncertainty
Verification overview: A requirement × verification-case matrix shows which checks exist and which are missing
Next actions: Failed process rules become open items, sorted by stage and assigned to a role
Safe rework: Evidence bound to content hashes goes stale when the design changes, so old results can't be reused by mistake
Requirements can be loaded from JSON, YAML or ReqIF, and requirement cards can be imported as unapproved requirements (dg model import-cards). An offline HTML viewer shows the graph without a server.
Guard rails for AI agents
Guard rails for AI agents
For agent work, the most important feature is what agents are not allowed to do.
Team & Agentic Orchestration: A manager role turns open items into tasks for expert roles such as the requirements engineer, and each role may write only certain parts of the model. An independent quality role then reviews every change. It sees the changed elements but not the author's reasoning.
Approvals: Agents can never write approvals, baselines, principals or tool declarations, and a review never counts as an approval. The final sign-off stays with a person. The orchestrator works with any LLM through a simple complete(system, user) function, so it is not tied to one vendor.
Case Study: FDM Printed Bridge designed by AI Agents
Case Study: FDM Printed Bridge designed by AI Agents
In order to validate the ontology works, I gave the design agent a simple engineering task in vague human language: "design a bridge that spans 45cm and is not wider than 20cm, it needs to be 3d printable using FDM. Propose the best filament for the job"
An AI agent then went on and designed a 734 g PLA truss bridge fully autonomously. Its FEM-calibrated model predicts first cracking at 5,048 N, about 700 times the bridge's own weight.
The final design, rendered from the FreeCAD assembly. Blue: central pieces; orange: end pieces; grey: end frames with board stops; purple: joint ties. Two printed girders carry the wooden board across the 450 mm gap
The Task in Detail
The Task in Detail
The brief was short: a bridge across a 450 mm gap, no wider than 200 mm, printed on a Prusa Core One+. No metal fasteners and no glue were allowed, and a wooden board rests on top.
The goal was a Pareto front of failure load against mass, where failure means first cracking.
The project had two goals:
deliver the bridge,
and assess how well the AI and the ontology support this kind of work.
The agent worked autonomously with FreeCAD (incl. the FreeCAD MCP) for CAD, and with Gmsh and CalculiX for finite element analysis (FEM).
Method first, design second
Method first, design second
The first few attempts went straight to a design with bolted splices and skipped requirements engineering. I discarded these, since the necessity for more guidance became obvious.
For the second major attempt the agent wrote down the method before any design work: nine stages, each with an exit criterion and named feedback paths.
Requirements: 17 stakeholder statements became 9 needs, 12 user requirements and 16 derived requirements, with 7 design rules and 8 assumptions. Statement coverage was 100 %. An audit added requirements the brief left implicit, such as "buckling counts as failure" and "the board must not slide off".
Concepts: Five structural concepts were screened against gates computed from the requirements. A twin Warren truss won; a solid-web girder was rejected because it needs 2.2 to 2.7 times the web material. Cutting the central piece as a trapezoid moved the tension joint and cut its force from 0.50 to 0.35 of the peak chord force.
Allowables: Strength and stiffness came from archived Prusament datasheets, reduced to characteristic values with a 0.90 process knockdown and marked provisional until coupons are tested.
Sizing: A frame model with twelve failure modes and 17 design variables fed an optimiser that produced the Pareto front.
CAD, FEM and rework: FreeCAD built the printable geometry and CalculiX checked it. Any disagreement between the models sent the work back to sizing.
Physical test: Well this I still need todo ;)
Key Results: Property & Value
Key Results: Property & Value
Material: PLA (Prusament)
Printed mass: 733.7 g from CAD; 731.5 g in the sizing model
Predicted first-crack load: 5,048 N (characteristic, provisional)
Overall size: 525.5 × 190 × 145.6 mm
Printed parts: 8 part types, 22 pieces, all on the print bed
Joints: dovetails, butt-and-key joints, captured and wedged tenons; no metal, no glue
Governing failure mode: deck frame cross bar
The CAD checks confirm the bridge spans the gap, stays within 200 mm width, has no interferences, and every part fits the printer. The CAD mass is within 5 % of the sizing model.
From below: the green deck frames brace the top chords against sideways buckling, and the purple ties lock the bottom-chord joints. No screws, no glue.
One girder, exploded at its joint. The dovetail at the bottom carries the chord tension; the key at the top aligns the butt joint, which is always in compression.
Top: one girder, with the dovetail joint J-2 in the bottom chord and the butt joint J-1 in the top chord.
Bottom: plan view, with the 200 mm width limit dashed in red.
The Pareto Front
The Pareto Front
Each frame highlights the lightest PLA design for one target load and draws its girder at true member widths.
From 150 N to 5,000 N the girder deepens from 40 mm to 101 mm and the mass rises from 255 g to 732 g. The governing failure mode moves between member tension (FM-01), the dovetail socket arms (FM-06) and, at the top, the lateral bracing (FM-12).
The front is nearly a straight line: about 250 g of fixed secondary structure plus about 0.1 g per newton.
It has no knee, so load per mass keeps rising up to the top of the searched range. PLA carries more load per gram than PETG over almost the whole range.
Models that check each other
Models that check each other
The biggest gains came from comparing independent models. Each comparison found a real error:
Dovetail wedge action: The joint flanks push the socket arms apart. A naive tension check overpredicted the joint by about 8 times.
CAD bugs: FreeCAD's 2-D fuse dropped faces and produced a 93 mm central piece. The CAD mass check caught it: 216 g against 367 g predicted.
Stress concentrations: FEM showed node hotspots 1.5 to 2 times the frame model's stress, while buckling was about 2 times less critical than assumed. Both became calibration factors fed back into sizing.
A diverging loop: In one run the FEM supports selected no nodes, so the model was a mechanism and the calibration factor ran from 1.0 to 21.5. A credibility gate now rejects any FEM run whose deflection differs from the frame model by more than 30 %.
Over four rework iterations the factors settled. The stress concentration factor for tension went from 1.0 to 1.90, and the buckling length factor from 1.0 to 0.63. The chart below shows how the gap between sizing and FEM closed.
Weight plates stacked on the bridge until the predicted first-crack load:
515 kg on 734 g of PLA. Each blue plate is 20 kg; the yellow one is the last 14.6 kg.
The plates are drawn thinner than real ones so the stack fits the frame.
The limit is the prediction of the FEM-calibrated frame model with characteristic PLA values; the physical load test is the next step.
The bridge's design record
The bridge's design record
The whole project is recorded in the current ontology: 17 stakeholder statements, 28 requirements, 20 failure modes, the trade study, the allowables, the verification cases and the evidence. That is 120 elements and 240 links.
The process rules turn what remains into a to-do list for the next round: independent reviews of the trade study and the analyses, a converged mesh study for the final FEM, the approvals only a person can give, and the physical load test.
Each box is one element of the model, and the lines are its typed links. A ring marks an open item: red for blocking work an agent role can do, amber for a warning, dashed grey for something only a person can close. Every requirement carries a dashed ring because none has been approved yet.
The gap is the middle-layer: Tool-driving agents need something that records why the design is the way it is and says what is still unverified. Standards such as SysML v2 and STEP describe the system and the product, but not whether an agent's claim has been checked.
Conclusion and how to try it
Conclusion and how to try it
An ontology won't make an AI agent a good engineer. What it can do is make the work traceable, stop an agent from declaring victory early, and tell it what to do next. The bridge showed how far an agent gets with a disciplined method.
The Design Intent Graph is open source under the Apache 2.0 licence and needs Python 3.12 or newer:
python -m pip install -e '.[dev]'
dg model assess examples/model_enclosure.yaml
dg process status examples/model_process_bracket.yaml
dg process plan examples/model_process_bracket.yaml
Well and for me: print ant test :D
Repository: github.com/leonemoritz/agentic_engineering_design_ontologogy
Page updated
Google Sites
Report abuse