From automated design reviews and requirements validation to component selection and manufacturing analysis, AI has the potential to dramatically accelerate product development. Yet as engineering organizations begin exploring AI, many are discovering that the technology is only part of the equation. Before AI can deliver meaningful results, the underlying engineering data must be structured, connected, and complete.
The reality is that most hardware development processes were built for human collaboration, not machine reasoning. Design files live inside proprietary CAD tools. Reviews happen over PDFs, screenshots, email threads, chat messages, and whiteboard sessions. Critical engineering decisions are often discussed in meetings but never formally documented.
That isn't a problem when engineers are talking to other engineers. It becomes a significant problem when AI is expected to understand, review, or reason about those designs.
Large Language Models (LLMs) don't think like engineers. They identify relationships and patterns within structured information. If the underlying engineering data is fragmented, incomplete, or missing the reasoning behind important decisions, AI has little meaningful context to work from.
The engineering and design teams that will realize the greatest value from AI won't just deploy better AI models. They'll build better engineering data to run AI agents on. In this blog I'll share my insights on the value of creating a strong data foundation and the importance of helping AI tools understand design intent.
Why unstructured and incomplete data limits the value of AI
PDFs are excellent for sharing design packages with reviewers. They are great at preserving information for consistency in an engineering process. ECAD files are ideal for engineers working inside design tools. Neither of these unstructured formats are particularly useful for AI.
Why does AI have a hard time with files that seemingly contain valuable information? When reading PDFs directly, AI models typically process files in sequence by opening, reading, and closing each document one by one, which becomes slower and more inefficient as the volume of files increases. This is where hallucinations creep in. The difficulty of identifying the correct passage often outpaces the model's ability to scan documents, causing it to miss critical evidence. Without this supporting information, models frequently fill in the gaps with fabricated answers. (Learn more about the challenge of AI PDF hallucinations.)
Similarly, screenshots, Gerber files, inspection photos, email conversations, and chat messages may capture pieces of the engineering process, but they lack the structure necessary for AI to extract information and reason across an entire design.
But rather than viewing engineering data as simply "AI compatible" or "not AI compatible," it's more useful to think of it as existing along a spectrum of AI readiness.
- Lowest AI readiness: PDFs, Gerber files, screenshots, inspection photos, chat messages, email discussions, binary CAD files. These formats contain valuable information for humans but provide limited machine-readable context to make them useful for AI.
- Moderate AI readiness: Netlists, XML or CSV bills of materials, Design Rule Check (DRC) reports, Electrical Rule Check (ERC) reports, simulation outputs. These files expose structured information that AI can begin analyzing, but they still represent only pieces of the engineering picture.
- High AI readiness: Native design data parsed into structured formats such as JSON or YAML, component metadata, requirements, review history, design rationale, engineering decisions. The closer your engineering data moves toward structured, connected information, the more capable AI becomes.
Version control: Organized and structured information for AI
Structuring engineering data is only half the challenge. AI also needs to understand how designs evolve over time. Every engineering change should be traceable, attributable, and searchable.
Version control creates this historical context that allows AI to answer questions about what happened, when, and some information on who made changes. Think of version control as the piping that helps organized information in a way that makes it useful
- When was this regulator replaced?
- Who approved this footprint modification?
- Which version introduced this manufacturing exception?
Organizations preparing for AI should establish three foundational capabilities before deploying AI agents:
- Comprehensive version control so every engineering change is traceable and attributable.
- Structured, machine-readable engineering data instead of relying on binary files and static PDFs.
- A centralized system of record where designs, requirements, reviews, simulations, approvals, and decisions all live together.
The closer your engineering data moves toward structured, connected information, the more capable AI becomes. But structure alone isn't enough. AI also needs to understand not just when, but how a design evolved. It needs to understand more than who made the change but why that decision was made. This historical context is what transforms engineering data into engineering knowledge.
The difference between data and design intent
Version history enables AI to identify what changed between two revisions and when the changes occurred. But it can't explain the engineering reasoning behind those differences. Even perfectly structured engineering data with tight version control only tells part of the story. AI can read what changed but can't understand why it changed. That "why" is design intent.
Design intent captures the reasoning behind engineering decisions, the tradeoffs that were considered, and the exceptions that were deliberately accepted. When AI can reason across an entire design history and the thinking behind decisions, it becomes significantly more valuable.
What does this look like in action? Let's consider a common supply chain scenario.
- An engineer approves a non-standard component because the preferred part has too long of a lead time.
- Months later, another engineer or an AI design review agent flags that same component as an error because it violates company standards.
Neither the engineer nor the AI is wrong. The AI simply lacks the context that the exception was intentional.
Without documented design rationale, AI will raise false positives because it cannot distinguish deliberate engineering decisions from actual mistakes. That's why high-performing engineering organizations need to capture more than design files.
Taking information from analog to digital
Much of what makes a great engineer isn't learned in textbooks or university classrooms. It comes from years of experience: whiteboard sessions where teams debate different architectures, conversations with manufacturing engineers, debugging hardware in the lab, comparing simulations against real-world measurements, discovering that two components with nearly identical datasheets behave very differently in production, learning which suppliers consistently deliver reliable parts. This accumulated experience is where many of the most valuable engineering decisions originate.
Unfortunately, very little of it is formally captured today. Instead, it lives in notebooks, email threads, Slack conversations, hallway discussions, meeting notes, and, perhaps most importantly, inside the minds of experienced engineers. So much of this information lives in the analog world. But for AI to understand design intent, it needs to be digital.
What can you do to start laying a stronger foundation for AI to learn from?
Design reviews should capture knowledge, not just approvals
It’s actually easy to start on this path. The goal is to put a process in place that's self-documenting, where your workflow already captures things as you go in a way that's helpful to you in the future, and also to AI agents.
Most organizations think of design reviews as quality gates. But really they are knowledge capture events. Every review generates valuable engineering context:
- Why a component was rejected
- Why an exception was accepted
- Why routing changed
- Why manufacturing requested a redesign
- Why reliability took priority over cost
- What requirements drove a design change
Once the meeting ends, much of that reasoning disappears. The design review becomes a spreadsheet with a screenshot and comments next to them. All the engineering knowledge behind those comments is lost. For AI, this missing context is enormous.
Capturing the conversations and answers in the design review helps document the design, transforming analog conversations into accessible, digital, and referenceable organizational knowledge. Future engineers and future AI systems can build on previous decisions instead of repeatedly solving the same problems.
All of this additional context transforms AI from simply reading documents into understanding the decisions behind them. Instead of identifying isolated issues, AI can evaluate decisions within their technical, historical, and organizational context. The organizations that benefit the most from AI won’t necessarily have the most advanced models, they’ll have the richest engineering knowledge for the AI models to learn from. That’s how to turn AI into a force multiplier.
The future of AI-driven hardware engineering
As hardware systems become more complex and engineering teams are asked to deliver more with fewer resources, competitive advantage will increasingly come from preserving engineering knowledge to leverage with AI tools. That means moving beyond PDFs, screenshots, disconnected spreadsheets, and isolated ECADs toward engineering systems that preserve not only what changed, but why.
When engineering data includes version history, structured relationships, design rationale, review discussions, and accepted exceptions, AI stops behaving like a sophisticated search engine and starts acting like a knowledgeable engineering collaborator.
The future of hardware engineering isn't about replacing engineers with AI. It's about capturing all of that hard-earned engineering knowledge in a form that AI can understand so engineers spend less time on known problems with known solutions and more time tackling tomorrow’s challenges. The greatest value of AI isn’t automating innovation. It’s really about creating more time for that discovery that pushes the envelope.
How to get started with AI
In this blog, I focused on the value of a strong data foundation and the importance of capturing the "why" that is often buried in experience and conversations. Next in this series, I get tactical: How to Know When to Use AI in Your Hardware Engineering Process covers exactly when to lean on deterministic automation, when to bring in AI, and when a human has to stay in the loop.
Further reading
Keep an eye out for the rest of this series:
- How to Know When to Use AI in Your Hardware Engineering Process: Blog 2 of 3
- A 90-Day Plan for Rolling Out AI in Engineering Teams: Blog 3 of 3
FAQs
How are the LLMs trained?
This is a great question that we get from hardware leaders to ensure the confidentiality of their proprietary design data. Here at Allspice, we do not train models. We focus on what the LLM (Large Language Model) space calls a harness. This harness enforces structural boundaries and provides the right instruction and data for the LLM. It also provides the foundational models for our AI agent to make the correct design decisions. We focus on providing the right types of data with the best processes for our AI agents to provide value while also ensuring that your internal data is kept confidential.
What is the biggest mistake hardware teams make when they first try to bring AI into engineering workflows?
Introducing AI as a standalone tool outside of existing workflows is the biggest mistake we've seen from customers. Engineers are already operating at max capacity, and asking them to step away from their day-to-day systems means the tools will likely get skipped. Successful teams weave AI tools directly into the process where the engineers are making decisions.
If a team's design data is messy or spread across ECAD, PLM, spreadsheets, and folders, where should they start?
A good place to start is version control. Ensure that your design changes are traceable and documented so that anyone, including an AI agent, can see facts like who changed what and when. From there, move to capturing the why and how in your design reviews. By documenting that information, organizations stop repeatedly paying for the same learnings, and AI can also learn the thinking behind decisions.
Claude Sonnet is now able to do review work. What advantages does it offer?
While Claude can provide reviews, you need to build your own LLM workflow every run. It also doesn't offer native data integration to work with your existing tools. Specialized AI systems, like our DRCY product, are built specifically for hardware design reviews. Instead of having to build your own LLM workflow every run, DRCY has access to all of that data natively. The end result is that it can make much more intelligent decisions than it would working from design exports or having to figure out how to fetch the data it needs. Further, since it's integrated into your design review process, you can work alongside your colleagues and trace back the full logical decisions.
