Reference · Version 1.0 · 2026-10-05

AI decision infrastructure for engineering

Deep Design Systems defines AI decision infrastructure for engineering as the layer between the tools that produce evidence and the people who decide. Its purpose is to keep the problem, the evidence and the reasons behind a choice open to scrutiny, including whether the problem itself is the right one, while a named person remains accountable for the decision.

Design Engines, the DDS platform built on this approach, is in development. Its first capabilities, framing the problem, tracing what was decided, by whom and why, and working with evidence from existing engineering tools, are being tested experimentally.

Why early engineering decisions are different

Engineering tools have become very good at solving well-defined problems. Once objectives, constraints and success criteria are fixed, simulation and optimisation can evaluate a design quickly and precisely.

Early industrial product development rarely offers a well-defined problem. Teams face four conditions at once:

Several stakeholders. Engineering, design, manufacturing, purchasing, customers and regulators each bring their own requirements.
Open objectives. What the product must achieve is still being negotiated.
Conflicting criteria. Performance, cost, mass, aesthetics, time, compliance and environmental impact pull in different directions.
Incomplete evidence. Commitments must be made before full analysis, testing or prototypes exist.

Here, early means before important commitments become difficult to reverse. A decision can still be early when a first geometry, prototype or analysis already exists.

Principles

The approach rests on four principles.

Question the problem, not only the options. New evidence can show that an objective was too narrow or that a constraint was only assumed. Revising the problem is a legitimate outcome, not a failure to decide.
Keep two boundaries apart. The scope of the problem sets which stakeholders, life-cycle stages and consequences are considered. The applicability of the evidence sets the conditions under which a result supports a claim. They change independently, and both must be explicit.
Accountability is not validation. A named person decides, and the reasons are recorded. Human review does not make an estimate scientifically valid: appropriate methods, relevant data and validation are still required for the claim being made.
Complement existing practice. Evidence comes from simulation, testing, life-cycle assessment, cost models and expert judgement. Decision infrastructure is designed to use that evidence, not to replace the tools or the people who produce it, and to apply the same logic across industries.

The path of a decision

Each decision can be read through five elements. They work as a guide, not as a fixed sequence: evidence can send the team back to an earlier step.

Requirement. What the product must achieve, and for whom.
Claim. What a design option is said to achieve against that requirement.
Evidence. What supports or contradicts the claim.
Boundary. The scope of the problem and the applicability of the evidence.
Human decision. An accountable person decides, knowing what is supported and what is not.

A decision is not always a choice between options. Depending on the evidence, a team may advance a direction, request further evidence, wait, keep a disagreement explicit or reformulate the problem.

How it relates to existing tools

Engineering software already covers many parts of product development, and some functions overlap. Decision infrastructure focuses on how their contributions inform a particular choice.

Category	Main contribution	What decision infrastructure adds
Simulation and CAE	Predictions of physical behaviour under defined conditions	Which options deserve that analysis, and what the results support
AI surrogate models and physics AI	Faster estimates of simulated behaviour	Places those estimates within a decision that weighs other criteria
Generative design	Candidate solutions for given objectives and constraints	Helps examine those objectives and constraints before and after generation
Product data and lifecycle systems	Versioned data and workflows	The reasoning behind a decision, not only its outcome
AI design review and knowledge tools	Checks against standards and lessons learned	Whether the problem being solved is the right one
AI assistants	Answers and drafts on request	Separation of evidence, opinion and accountable decision

Illustrative example

Hypothetical example. It does not describe a DDS result, a customer project or a current product capability.

A team plans to make an industrial component modular so that it is easier to repair. The initial scope covers manufacturing and repair.

Widening the scope to the full life cycle, and looking at how the component actually fails in service, could show that the added manufacturing impact outweighs the repair benefit in typical use. The question then changes: from how do we make it modular? to what is the best way to keep it in service? Better availability of spare parts could become the stronger option.

The value of decision infrastructure in this case is not a better score for the original plan. It is noticing that the question had to change, and recording why.

Where it adds most, and where it adds less

It adds most while objectives, constraints and evidence are still being discussed, and when a decision will be hard to reverse.
It adds less to well-defined optimisation problems, although traceability can still be useful there.
It does not replace validation, high-fidelity simulation, physical testing, certification or engineering judgement.
It cannot create evidence that does not exist. It makes the gap explicit.

Deep Design Systems

Deep Design Systems (DDS), an official spin-off of the Universidade da Coruña linked to the CITIC research centre, builds AI decision infrastructure for complex problems in early industrial product development.

Design Engines (in development) is the DDS decision platform built on the principles above. Problem framing, decision traceability and tool-agnostic evidence intake are currently in experimental testing.
DDS Aeroflow is built for the earliest design stages, before CAD, when a full CFD analysis is not yet possible. It compares concept proposals aerodynamically and shows which ones are worth developing further, so high-fidelity simulation, and its cost, is spent only on the options that deserve it. A compass before CFD, not a replacement.

Engineering tools solve well-defined problems faster. Design Engines helps when the problem itself is not yet well defined.

Explore the platform →

Frequently asked questions

What is AI decision infrastructure for engineering?

In the sense used by DDS, it is the layer between the tools that produce evidence and the people who decide. It keeps the problem, the evidence and the reasons for a choice open to scrutiny, while a named person remains accountable.

How is it different from simulation or AI surrogate models?

Simulation and surrogate models estimate how a design behaves under defined conditions. Decision infrastructure concerns how those estimates, together with other evidence and priorities, inform a choice, and where they stop applying.

How does it relate to generative design?

Generative design can contribute candidate solutions. Decision infrastructure examines what the team is trying to achieve, which alternatives deserve investigation and what evidence would justify advancing them.

What happens when criteria conflict or evidence is incomplete?

There may be no option that is best on every criterion. The trade-off and the remaining uncertainty are made explicit, and the team may advance, seek more evidence, wait or reconsider the question. Missing evidence is never treated as a favourable result.

Does human review validate an AI result?

No. Human review is necessary for responsible use, but it does not make an estimate scientifically valid. Appropriate methods, relevant data and validation remain necessary for the claim being made.

References

Background on decisions with multiple objectives and on evaluating design alternatives. These references do not validate Design Engines.

Keeney, R. L. and Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Tradeoffs. Cambridge University Press. First published 1976, Wiley.
Pugh, S. (1991). Total Design: Integrated Methods for Successful Product Engineering. Addison-Wesley.
Sobek, D. K. II, Ward, A. C. and Liker, J. K. (1999). Toyota's principles of set-based concurrent engineering. Sloan Management Review, 40(2), 67–83.

Version 1.0 · 2026-10-05 · Deep Design Systems · José R. López-Gonzalo, José A. Iglesias-Guitián, L. Omar Álvarez-Mures