Modern AI tools are becoming very good at producing plausible answers. That is useful in many contexts, but it becomes dangerous when we move into technical validation: CAD layouts, BIM models, engineering specifications, compliance checks, safety constraints, or any workflow where the answer must be correct for a defined reason.
In these environments, the question is not simply:
“Can the AI answer?”
The better question is:
“What is the source of truth, and can the system explain it?”
That distinction matters. If we allow an LLM to freely decide whether a technical system is valid, we are giving a probabilistic language model responsibility for something that should often be handled by deterministic logic. The better architecture is different: let deterministic rules validate the system, then let AI explain the result.
The problem with free-form AI validation
A typical AI chatbot is optimized to be helpful. If you ask it whether something looks correct, it will often try to answer even when it does not have enough evidence. That behavior is useful for brainstorming, but risky for engineering workflows.
Imagine a system that reviews a warehouse layout, a building plan, or a BIM model. The user might ask:
“Does this layout comply with the required accessibility constraints?”
A free-form AI assistant may produce a confident answer based on partial context. It might infer missing information, smooth over uncertainty, or explain something that was never actually checked. That is not acceptable when the output affects design decisions.
In technical validation, “sounds right” is not enough. The system needs to know:
- Which rule was checked?
- Which object or element was evaluated?
- What evidence supports the result?
- Was the result pass, fail, or unknown?
- What data was missing?
- Which part was deterministic and which part was AI-generated?
Without this separation, AI explanations can become dangerous because they appear authoritative while hiding uncertainty.
Deterministic rules should be the source of truth
For technical validation, deterministic code should own the actual decision whenever possible.
That means rules should be implemented in a way that produces predictable outputs. For example:
if (door.width < requiredMinimumWidth) {
return {
status: "fail",
rule: "MIN_DOOR_WIDTH",
evidence: {
actualWidth: door.width,
requiredWidth: requiredMinimumWidth,
doorId: door.id,
},
};
}
This kind of logic is not glamorous, but it is reliable. It gives us a clear reason for the result. It can be tested. It can be reviewed. It can be improved. Most importantly, it does not invent missing information.
The AI layer should not replace this logic. Instead, it should receive the structured result and explain it in a way that is useful to the user.
The rule engine says:
{
"status": "fail",
"rule": "MIN_DOOR_WIDTH",
"actualWidth": 820,
"requiredWidth": 900,
"element": "Door D-14"
}
The AI explains:
Door D-14 does not meet the minimum required width. The detected width is 820 mm, while the required minimum is 900 mm. This means the opening is 80 mm too narrow and should be reviewed before the layout is accepted.
That is a much safer pattern.
The AI is not deciding truth.
The AI is translating verified evidence into a human-readable explanation.
The architecture pattern: rules first, AI second
The pattern I prefer looks like this:
Technical model / document / structured data
↓
Normalization layer
↓
Deterministic validation engine
↓
Evidence object
↓
AI explanation layer
↓
User-facing explanation
Each layer has a clear responsibility.
The normalization layer turns messy input into a consistent internal structure. In CAD/BIM-style workflows, this could mean converting Revit or AutoCAD-related data into a simpler JSON representation: levels, rooms, doors, zones, measurements, constraints, and relationships.
The deterministic validation engine checks explicit rules. It does not guess. It returns pass, fail, or unknown.
The evidence object stores the reason behind the result. This is crucial. If there is no evidence, the AI should not be allowed to pretend that there is.
The AI explanation layer receives only the validated context. Its job is to explain, summarize, translate, and guide. It should not silently create new facts.
Unknown should remain unknown
One of the most important states in AI-assisted technical systems is:
“Unknown”
Many systems only think in terms of pass or fail. But in real workflows, missing data is common.
A model may not contain a required measurement. A document may not specify a threshold. A layout may be incomplete. In those cases, the correct answer is not a confident pass or fail. The correct answer is:
“The system cannot determine this from the available evidence.”
This is where AI needs strong constraints. It should not fill the gap just because the user expects an answer.
For example:
{
"status": "unknown",
"rule": "EMERGENCY_EXIT_DISTANCE",
"reason": "Missing travel distance data",
"requiredEvidence": ["exit location", "path distance", "room occupancy"]
}
The AI can then explain:
This requirement cannot be validated because the model does not include enough information about travel distance to the emergency exit. To complete the check, the system needs the exit location, path distance, and room occupancy data.
That is much better than hallucinating a compliance result.
A trustworthy AI system should be comfortable saying:
“I do not know based on the available data.”
Why this matters for CAD, BIM, and engineering workflows
CAD and BIM workflows are built around structured technical information. They are not just drawings or visuals. They contain relationships, constraints, dimensions, layers, objects, spaces, and specifications.
That makes them a strong fit for AI-assisted workflows, but only if the architecture respects the nature of the data.
A good AI assistant in this context should not behave like a generic chatbot. It should behave more like a technical reviewer:
- grounded in model facts
- aware of constraints
- clear about missing information
- able to explain validation results
- unable to invent unchecked conclusions
For architects, engineers, and design teams, this distinction is important. They do not need an AI that confidently says “looks good.” They need a system that can say:
“This passes because these three constraints were satisfied.”
or:
“This fails because this measurement is below the required threshold.”
or:
“This cannot be validated because the model is missing this data.”
That is where AI becomes useful: not as a replacement for engineering judgment, but as an interface for understanding structured validation.
A small prototype: AI-assisted spec validation
I recently built a small prototype to explore this idea: an AI-assisted specification validator.
The goal was not to build a full production CAD or Revit integration. The goal was to test an architectural pattern:
deterministic validation first, AI explanation second.
The prototype works with structured technical input and produces validation results based on explicit rules. The AI assistant can then explain those results, but only within the available evidence.
The key principles were:
- The rule engine is the source of truth.
- AI explains results; it does not create them.
- Missing data produces an unknown state.
- Outputs should be structured and reviewable.
- The user should be able to trace why a result was produced.
This is the same mindset I believe should apply to many AI systems in technical domains: compliance, security questionnaires, CAD/BIM validation, document analysis, and engineering review.
Where LLMs are useful
This does not mean LLMs are not valuable. They are extremely useful when used in the right layer.
LLMs are strong at:
- explaining technical results in plain language
- summarizing complex evidence
- mapping user questions to relevant checks
- translating domain terminology
- helping users understand what to fix
- generating structured drafts from verified context
- guiding users through incomplete information
They are weaker at:
- being the source of truth
- guaranteeing correctness
- performing hidden validation without evidence
- knowing when data is missing unless explicitly constrained
- maintaining consistency without structured inputs and guardrails
So the question should not be:
“Can AI validate this?”
The better question is:
“Which parts should be deterministic, and which parts should AI explain?”
That framing leads to better systems.
Testing matters more than demos
A demo can look impressive even if the underlying system is fragile. That is especially true with AI. A model can produce one excellent answer during a demo and fail silently in edge cases.
For technical validation systems, testing needs to cover both deterministic logic and AI behavior.
The deterministic layer should have normal unit and integration tests:
- does the rule pass when the data is valid?
- does it fail when the measurement is below the threshold?
- does it return unknown when required evidence is missing?
- are edge cases handled correctly?
The AI layer needs a different kind of evaluation:
- does the explanation stay within the evidence?
- does it avoid adding unsupported claims?
- does it clearly communicate uncertainty?
- does it preserve the correct rule status?
- does it help the user understand the next action?
The AI output is not just a text response. It is part of the user’s decision-making process. That means it needs to be evaluated carefully.
The practical takeaway
In technical workflows, AI should not be treated as a magical reasoning engine that replaces deterministic validation.
A better pattern is:
Use code for truth.
Use AI for explanation.
Use evidence as the boundary.
That architecture is less flashy than a fully autonomous agent, but it is much more trustworthy.
If a deterministic rule can check something reliably, let code check it. If the result needs to be explained, translated, summarized, or made useful to a human, let AI help.
The future of AI in engineering will not be built only on more powerful models. It will be built on better system design: clear boundaries, structured evidence, deterministic checks, and AI explanations that know what they are allowed to say.
AI should explain technical validation.
It should not invent it.
Top comments (0)