AI & engineering
AI in engineering software: what should remain deterministic?
A practical boundary for using AI in engineering software without handing calculations, compatibility or governed product facts to a probabilistic model.
Engineering software often contains two very different kinds of difficulty. Some work is difficult because the input is messy, incomplete or expressed in natural language. Other work is difficult because the rules, calculations and product constraints are precise. AI can help strongly with the first category without being allowed to own the second.
The useful design question is therefore not “where can we add AI?” It is “where does probabilistic interpretation help, and where must the system produce the same governed result from the same approved facts?”
Where AI is naturally useful
Models are well suited to interpretation. They can help locate relevant passages, classify an incoming enquiry, prepare a summary or extract possible fields from a technical document. These tasks are expensive for people precisely because the source is inconsistent and the meaning is not represented as structured data.
Used well, AI reduces the effort required to turn that ambiguity into a reviewable starting point. It does not need to claim authority over the engineering outcome to be valuable.
- Extract candidate product attributes from a datasheet for validation.
- Identify possible application requirements in an email or specification.
- Search controlled technical documents and return source-linked passages.
- Summarise a case or prepare a draft explanation for an engineer to review.
What should usually remain deterministic
A deterministic rule produces the same output from the same approved inputs. That behaviour is essential when the system is applying formulae, limits, compatibility constraints or permissions. The logic can be tested against known cases, reviewed directly and changed through a governed process.
Putting a language model between approved inputs and a pass/fail engineering decision makes the result harder to reproduce and explain. Even when the model often reaches the expected answer, the architecture has weakened the control that the calculation or rule was meant to provide.
- Engineering calculations and unit conversion.
- Ratings, thresholds and pass/fail criteria.
- Product compatibility and available combinations.
- Approved catalogue facts and revision status.
- Permissions, approvals and commercial authority.
Use a proposed-record boundary
A practical pattern is to let AI prepare a proposed structured record rather than writing directly into the governed source of truth. Each extracted field can retain its source, confidence or review note. Deterministic validation then checks units, required values, allowable ranges and relationships before a person approves the record.
This boundary makes the model replaceable and keeps the controlled workflow understandable. It also provides useful feedback: recurring corrections reveal where prompts, source documents or the extraction schema need improvement.
Design the interface around uncertainty
An AI-enabled screen should not make a suggestion look identical to an approved fact. Users need to see which content came from the source, what the model inferred and which part still needs review. Confidence can be useful, but it should support judgement rather than act as a substitute for it.
When the model cannot find enough evidence, “needs review” is a valid system outcome. A workflow that handles uncertainty honestly is more useful than one that always produces a confident-looking answer.
Keep the engineering core model-independent
The calculation and rules layer should accept structured inputs and return structured results regardless of whether those inputs were entered by a person, imported from a system or proposed by AI. This separation prevents the product from becoming dependent on one model or prompt for its engineering integrity.
It also supports better testing. Deterministic logic can be covered with fixed cases, while the AI boundary can be evaluated for extraction quality, source use and review behaviour. The two components have different failure modes and deserve different controls.
Choose the first use case by workflow value
Start where unstructured information creates a clear bottleneck and a person already knows how to review the result. Technical data preparation, enquiry triage and source-aware search are often stronger first candidates than asking a model to recommend a product or approve an engineering decision.
The goal is not to minimise human involvement at any cost. It is to let people spend less time transcribing and searching, while the software keeps important facts, rules and decisions explicit.