SI
AI
EDA3.0
The Watchtower Brief
Signals, strategy, and hard-earned lessons from the front lines.
Nobody sets out to make the bill of materials interesting.
For most of my career it was the back of the document. The part you filled in after the real work was done. I designed chips, spent years in the field and a good while inside an IDM as a PM, and in all of it the BOM was a parts list - something a tool spat out, something procurement cared about, something you checked once and forgot. It was plumbing.
It is not plumbing anymore.
Two things changed, and they changed at the same time. The first is regulation. CHIPS Act traceability, export-control reporting, customers asking harder and harder questions about security of supply - all of it has moved the BOM from a hygiene item to something a board has to be able to stand behind. The question on the table at a lot of companies right now is plain: can you produce a defensible bill of materials for any product you shipped in the last year, on demand, with lineage an auditor will accept? A year ago that question lived with a compliance officer. Now it lives with the VP of engineering, and sometimes higher than that. The second is the silicon itself. We have moved from monolithic chips to multi-die packages, and the BOM has exploded along with them. Every chiplet, every piece of third-party IP, every UCIe link, every bit of packaging lineage is now a line that has to be captured, attested, and traced. We all knew chiplets would complicate design. Fewer of us noticed they would complicate the paperwork just as much.
So the BOM is travelling from one thing to another. From a static list you generate at the end, to a living, governed source of truth you maintain the whole way through - one a machine can read and a regulator can trust. That is the real vector. Some teams have started to give it a name. The one I keep hearing is OneBOM: one bill of materials, captured once, governed once, exposed once. The label matters less than the shift behind it.
Two honest bets
Underneath that shift sits a real argument about how to build the thing, and the industry has split into two camps. One camp builds it the structured way. Top-down. A governed model, a proper digital thread, the BOM defined up front and everything made to conform to it. The engineers feed it; the discipline is in the writing. Database people call this schema-on-write.
The other camp does the opposite. Pour everything into a data lake, keep the structure loose, and point AI at it to pull a BOM out whenever you need one. Schema-on-read. The bet is speed - don't slow the engineers down with governance they will route around anyway, and let the model sort it out later.
| The structured bet | The data-lake bet | |
|---|---|---|
| Database term | Schema-on-write | Schema-on-read |
| How it's built | Top-down governed model; the BOM defined up front, everything made to conform. | Pour everything into a lake, keep structure loose, point AI at it on demand. |
| Who tends to choose it | The IDM — decades of process discipline, a lot to lose from a bad audit. | The fabless — fast, allergic to anything that reads like top-down PLM. |
| The wager | Do the unglamorous governance up front. | Don't slow the engineers down; let the model sort it out later. |
Two honest bets, side by side. How each tends to age is taken up below — offered as a pattern, not a verdict.
Both are reasonable, and I want to be careful here, because it is easy to be glib about a choice other people had to make under real constraints. The structured camp is usually an IDM with decades of process discipline and a lot to lose from a bad audit. The data-lake camp is usually fabless and fast, allergic to anything that reads like top-down PLM, and not wrong to be. Neither chose foolishly. They answered the same question with different instincts.
I will offer one observation, and only as a pattern I have watched rather than a verdict. Pointing AI at a lake gives you a wonderful first quarter. The demos are great. Then it tends to flatten, because the time you saved on extraction you start spending on reconciliation - chasing the confident answer that turns out to be wrong, sorting the false positives, proving the lineage the model could not show its working on. Structured data does the unglamorous work up front and tends to compound. Loose data front-loads the reward and tends to plateau. That is not an argument against AI. It is an argument about what you feed it.
Sell the artifact, not the AI
Which brings me to the part I most want to get across, because it is where I watch good companies lose the room.
Do not sell the AI. Sell the artifact.
A VP of engineering does not have a budget line for "AI integration." It is too abstract, and engineers can smell a story that has floated loose from how the technology actually works. They will not correct you in the meeting. They just will not take the next one. But a bill of materials that an auditor will accept, an export-control officer will sign, and a customer will trust - that is a concrete thing, and concrete things get funded. The deliverable is the wedge. The platform comes later, if it comes at all.
This is also, to me, the clearest example of what AI is for. The grind in a BOM - the manual reconciliation, the spreadsheet lookups, the cross-checking at eleven at night that nobody should be doing by hand - is exactly the work to hand to a machine. What is left is the judgment about what the artifact has to prove and to whom, and the relationship with the person who has to put their name on it. AI takes the grind out. It does not take the job.
The seam nobody owns
There is a gap in most of these companies that nobody quite owns. The data from the fab floor does not make it back to the design teams. The data from the engineering teams does not make it into the compliance artifacts. Each side assumes the other has it. That unowned seam, between the engineering that builds the product and the compliance that has to vouch for it, is where this whole opportunity lives. It is why John and I have spent so much time here with the partners we work with at that layer, SoftWeb among them. The companies that win will not be the ones with the cleverest model. They will be the ones who close that loop and make the artifact trustworthy.
As for how you actually get into one of these accounts - and this is the oldest lesson I have - you listen first. We write a dossier before we ever build a deck, because you have no business standing in front of an engineer asking them to buy until you understand their problem better than the average person inside their own building. And in the room itself, the move is not to pitch. It is "that sounds interesting, tell me more." Most of the real work happens in the hallway afterwards, or the next day, when a technical paper lands and they read it without you watching. There is an instinct for the moment interest turns into intent, and the window is tighter than you think. You do not get there by talking through it.
I have been around the bill of materials for thirty years, and somehow it took regulation and chiplets to make me find it interesting. So take all of this as one person's read of a fast-moving thing, nothing more. I would love to know how others are seeing the structured-versus-lake question, especially anyone living inside it. If any of this is useful to someone a little earlier on, it was worth writing. Any thoughts greatly appreciated.
— Simon
First in this series
Before the artifact, the loop: why a hardware company can't close the field-to-engineering gap with its incumbent SI or an offshore team — and the partner profile that does.
Read Part 01 — Closing the field-to-engineering loop → | Explore Softweb →
The Watchtower · AI Tech Sales — ai-techsales.com
