Could AI Have Found Your Build Blocker?

Think about the last time a project became stuck. A component did not arrive. A supplier produced an earlier revision. An assembly team discovered that its instructions described a different configuration. Or an unresolved decision finally reached the person who could make it, after the useful options had narrowed.

Once the problem was visible, its history probably became easier to explain. Someone found the supplier email. Someone opened the applicable drawing. Someone remembered the discussion in which an assumption had been made. The team assembled a story about how it happened.

Now rewind two weeks. Could you have assembled that story then?

That is the question I want to explore with OpenBOM Launch Master. Could an AI-assisted build readiness review have identified a useful warning from the information available before a blocker became obvious?

In my earlier article, Who Is Holding Your Product Launch Together?, I described the coordination behind a complex delivery. I also explored how product delivery starts long before the launch. Here, I want to make the next step more concrete: define a method and a fair way to test it.

My starting point is a Build Readiness Model, populated from the information a team already uses and connected through OpenBOM’s Product Context Graph. The practical result we want to evaluate is a blocker and action report that helps someone decide what needs attention before the build.

Rewind the records as well as the story

A retrospective test needs a clear cutoff. If we choose the information available two weeks before assembly, we should use the BOM, supplier responses, inventory records and plans available at that point. A corrected drawing issued after the problem was discovered cannot explain what an earlier review should have found.

The same applies to the explanation. Giving an AI the eventual root cause and asking it to find supporting evidence would test its ability to reconstruct a known story. To test earlier detection, we should withhold the outcome from the review and compare the findings afterward. Where practical, the person preparing the historical records should be different from the person reviewing them.

We also need to identify the commitment under review. Which product configuration? How many units? What milestone and required date? A report about the product in general can collect many observations without establishing which ones matter to the build in question.

The first package can be straightforward: exported spreadsheets, engineering documents, supplier confirmations, open issue records and the relevant assembly plan. We can begin with files the team already knows how to produce. That creates a bounded experiment without first making live connections to every source system.

The package will have gaps. Some decisions may exist only in conversations. Some files may have uncertain dates. Record those limitations. They help establish what the review could reasonably know and where someone would need to ask a question.

Interviews can help reconstruct those gaps, but we should keep recollections separate from dated records. A person may now understand a supplier’s message differently because they know what happened afterward. If we add clarification during the test, record the question, the answer and whether that answer could have been obtained at the chosen cutoff. That lets us evaluate both the initial document review and the value of the follow-up questions it generated.

A Build Readiness Model gives the review a structure

Before comparing records, we need to establish what they describe. A purchasing spreadsheet might identify a supplier’s assembly number. The BOM might use an internal part number. A drawing might include another reference. Even the word “available” could mean physically received, expected from a supplier or reserved for another order.

I use Build Readiness Model to describe a common way of organizing the information needed for a specific build. Technically, this is a canonical model: different source formats map to shared concepts without requiring every company to organize its systems identically.

The model starts with the build commitment and connects it to the required product configuration. It includes the applicable parts and revisions, quantities, sourcing arrangements, availability, manufacturing operations and instructions. It also needs the evidence behind important commitments and the people who can resolve open questions.

These concepts give imported information a consistent meaning. A supplier promise becomes a dated statement about a particular item and quantity. An assembly instruction becomes evidence associated with an operation and an applicable configuration. A BOM revision identifies the product definition being evaluated.

Dates need the same care as part identities. Dispatch, receipt, inspection and availability at an assembly station describe different events. Quantities can also mean ordered, received, accepted or allocated. Mapping these distinctions correctly matters more than putting every date or number into a common column. The model should retain the meaning supplied by the source and make any interpretation visible for review.

The scope should remain practical. If the next milestone concerns one subsystem, we can examine that subsystem and its relevant dependencies. We do not need to reconcile every record in the company. Equally, the conditions for an experimental prototype can differ from those required for a production build. The team needs to establish which attributes and approvals matter for the chosen milestone.

This is why the model must accommodate different organizations. An enterprise may export information from several managed systems. A smaller manufacturer may provide spreadsheets and drawings. Both can describe parts, suppliers and operations, although the completeness and reliability of their records may differ considerably.

The value of a common model is that it gives the review a repeatable set of concepts while leaving room for those differences.

Connect the evidence through a Product Context Graph

The model describes what we need to understand. The project records provide the evidence for a particular build. Connecting those records is the role we want the Product Context Graph to play in this review.

I have described OpenBOM’s Product Context Graph as the connected context around product definition, decisions and commitments. For the Launch Master experiment, the relevant question is how that foundation can support reasoning across imported engineering, sourcing and manufacturing data.

Consider the connections needed to examine a purchased assembly. The review needs to establish which BOM item it satisfies, which supplier reference identifies it, which drawing applies, what quantity was promised and when the assembly operation needs it. Those facts may appear in several files maintained by different people.

In the proposed workflow, we would map the imported records into the Build Readiness Model and establish the supported relationships between them. A shared part number might provide strong evidence of identity. A similar description might suggest a possible match that requires confirmation. The review must preserve that distinction.

Sources and dates belong with the connections. An old quotation and a recent supplier confirmation should remain distinguishable. Conflicting statements should remain visible. Choosing one value simply to make the model look complete could erase the disagreement the review needs to investigate.

This connected context gives the review a basis for following a question across records. It can examine whether the item being supplied supports the intended configuration and whether its availability supports the planned operation. When the evidence is incomplete, it can identify the missing confirmation.

The graph does not manufacture knowledge that the team never recorded. Its usefulness depends on the quality of the evidence, the correctness of the connections and the questions asked of them.

The blocker matrix makes the questions systematic

We have been developing a matrix of build readiness questions across BOM, CAD and PDM, sourcing, supply chain, routing and process instructions. Its purpose is to organize checks within each area and across the relationships between them.

For example, a BOM check can examine whether the applicable configuration has a definitive parts list. A check between the BOM and sourcing can ask whether every required purchased part has an identified source for the correct version. A check between the BOM and availability can ask whether the quantities needed for the build can be obtained by the required date.

Other checks connect engineering to supplier documents, parts to assembly operations, and operations to instructions. These are useful starting questions. Their interpretation depends on the product and the milestone, and the initial matrix will need to develop through actual cases.

The distinction between the matrix and the graph matters. The matrix guides the relationships to examine and the questions to ask. The customer records supply the specific parts, commitments and evidence being examined. A populated matrix cell does not establish that a customer’s build is ready.

Some checks can be straightforward comparisons once identity, revision and scope are established. Others may require AI to interpret a document or suggest a relationship for review. Technical compatibility may require engineering evidence or specialist judgment. The report should make those differences understandable to the person using it.

We should also distinguish an inconsistency from an unknown. A supplier confirmation that specifies an inapplicable drawing is different from a record that says nothing about the drawing. Both deserve attention, but they lead to different questions and potentially different actions.

Follow one hypothetical finding from source to action

Imagine a team preparing eight industrial inspection machines for assembly on October 12. We freeze the records as they existed on October 1. This is an illustrative example, not a result from a completed customer test.

The build BOM requires eight units of actuator assembly AC-104 using drawing revision C. An approved reference list maps that internal item to supplier item VX-27. The supplier’s acknowledgement identifies drawing AC-104 revision B and promises dispatch on October 14. The inventory export shows no units available for this build. The assembly instructions refer to revision C.

The connections expose two questions. Does the acknowledged assembly satisfy the intended configuration? And what confirmed supply supports an operation scheduled before the stated dispatch date?

These comparisons are simple once the relevant records have been connected. A date check may need no AI at all. The work to evaluate is whether we can reliably establish the applicable items, documents and commitments with less manual effort, then present the resulting issue in a form people can use. The experiment should make that contribution visible instead of attributing every comparison to AI.

A useful report could identify the following finding:

Actuator supply for the October 12 assembly is at risk. The current build requires eight AC-104 assemblies to drawing revision C. The supplier acknowledgement references revision B and dispatch on October 14. The supplied inventory record shows no available units for this build. The review found no documented revision acceptance or alternative supply commitment in the provided records.

The finding should link to the BOM entry, reference list, supplier acknowledgement, inventory record and assembly plan. That lets the team inspect the reasoning and correct any mistaken interpretation.

The next actions follow from the uncertainty. Engineering needs to establish whether the acknowledged revision is acceptable or requires correction. Purchasing needs an updated commitment for the required configuration and quantity. The build owner needs to assess the effect on the assembly plan.

The report cannot assume that revision B is physically incompatible. There might be an approved exception outside the supplied records. There might also be an earlier shipment that has not been documented. Those possibilities are reasons to obtain evidence, rather than reasons to silently assume the build is covered.

Closure requires the relevant confirmations: technical acceptance, an achievable supply arrangement and an assembly plan consistent with them. Assigning a task begins that work; it does not establish that the risk has been resolved.

Decide what would count as a useful result

Once the review is complete, we can compare its findings with the actual history. Did it identify the eventual blocker? Did it explain the dependency correctly? Most importantly, would the finding have reached an accountable person while a useful action was still possible?

The experiment also needs to examine false alarms. A report that flags every blank cell may be comprehensive in appearance while adding little value. Findings should be relevant to the selected build, supported by evidence and understandable without another lengthy investigation into what the report means.

We should record missed blockers as carefully as detected ones. Was the necessary information absent? Did the review fail to connect two records? Was the relevant question missing from the matrix? Or did the issue require technical knowledge or a conversation that the supplied material could not provide?

A review that finds no blocker also needs to show its coverage. If supplier evidence was complete but assembly instructions were unavailable, the result should explain that boundary. The absence of a finding cannot establish readiness in areas the review could not examine. This gives the build owner a useful distinction between conditions checked successfully and conditions still waiting for evidence.

These explanations tell us how to improve the approach. They also help separate work that software can make repeatable from work that remains dependent on experienced delivery judgment.

Preparation effort matters. We should measure the time needed to collect files, clarify identities, review proposed connections, assess findings and prepare the report. A useful warning has less commercial value if producing it requires more effort than the existing review process. Repeating the exercise on a later snapshot can show whether the initial organization makes the next review easier.

One retrospective case would give us evidence about that case. Repeating the test across different products and teams would help establish where the model travels well and where it needs adaptation. We should also look at builds that proceeded successfully, so the test rewards justified restraint as well as finding problems.

A practical next step for Launch Master

The first result I want to test is a blocker and action report for one defined commitment. The team should be able to see what requires attention, which records support the finding, what remains unknown and who needs to establish the next answer.

Software and AI would help produce that review. The people responsible for engineering, procurement and delivery would assess the findings and make the decisions. The report’s value would come from whether it saves preparation effort or helps them take a useful action earlier.

Launch Master remains an exploration. The Build Readiness Model and blocker matrix give us a way to structure the work, while the Product Context Graph provides a foundation for connecting the evidence. Testing them against real project records is how we can find out what they contribute.

If you manage launches, NPI programs or complex manufacturing deliveries, I would be interested in examining one past build blocker with you. The starting point is the record available before the problem became obvious, together with a clear description of the milestone the team was trying to reach. We can then compare the review with what you actually learned and did.

What would we have needed to connect, two weeks earlier, to see your last build blocker coming?

If you have a case to discuss, contact me at oleg@openbom.com.

Best, Oleg