What Can We Build, and When? The Question Behind Every Parts List

“Can we support 10 units by November 8?”

Picture that question coming up in a planning, production or even sales meeting. The person responsible for answering it might be a program manager, an engineering lead, or the buyer who has gradually become the person everyone asks.

Before the meeting, that person has already done some homework. They checked the BOM with engineering, asked purchasing about suppliers, pulled the stock report, and followed up on a delivery date. During the meeting, another question appears: does the supplier’s answer cover the revision selected for this build?

Now they need to go back and check.

An answer requires contributions from several people. Engineering establishes the applicable product definition. Purchasing confirms sources and the meaning of supplier commitments. The person managing inventory supplies the stock position. The build owner brings those answers together around a quantity and a material need date.

The parts list is one starting point. The work continues until someone can explain what supports the build, what remains unresolved, and who needs to act.

Why we organize the information

In some of our customer discussions at OpenBOM, I see a practical purpose behind requests to organize parts, BOMs, engineering files, and sourcing information. People want to use those records to answer a question about a specific product or an order they build.

They need to know which parts to obtain, whether the engineering information confirms the plan, and what they can reasonably commit to with the material and components available.

That observation does not describe every customer or every use of a BOM. It does help explain why a well-organized set of records can still leave important work for the person coordinating a build.

A part has a supplier. A purchasing record has a date. A stock report has a quantity. Someone still has to establish whether those answers apply to this product configuration, this requested quantity, and this material need date.

That is the work I want to make more tangible as we develop OpenBOM Launch Master.

The reconciliation behind the answer

Start with the applicable design. Which configuration and engineering revision define the product or build? Which BOM quantities apply? Are the supporting design records connected to the right Items?

Then establish demand. Ten products might require ten motors, fifty valves, and twenty guide rails. For a complex product with a multi-level BOM, the team also needs an aligned basis for deciding which assemblies and components must be supplied.

Next comes the material position. How much stock is available according to the records accepted for this review? What is short? Which shortages have applicable purchase evidence, and which still require an order?

Dates introduce another layer. A quoted lead time and an existing purchase order provide different evidence. A supplier’s dispatch date needs additional information before it can establish when material will be usable at the build location.

Finally, there are the unanswered questions. A source is missing. A drawing reference is unclear. A supplier’s engineering reference differs from the required revision. The person preparing the answer needs to keep these uncertainties visible and get them to someone who can resolve them.

Some teams organize part of this work through a plan for every part. Others combine ERP reports, spreadsheets, engineering reviews, supplier correspondence, and regular meetings.

How do you do it today? Who assembles the answer, and what do they have to reconcile before the team trusts it?

What one build review could show

Consider a fictional industrial test module. This is an illustrative example of the result we want to evaluate with Launch Master.

Morgan owns the build. The team is reviewing the Standard A configuration on November 2, 2026. The requirement is 10 units, with usable material needed by November 8.

Assume that the per-product requirements are agreed and the supplied stock quantities are valid for this assessment. All other required materials have enough recorded stock; two Items constrain the quantity:

The material calculation supports six complete product units now, constrained by the valves.

A useful summary would keep the rest of the situation alongside that number:

Build: 10 Standard A units. Material need date: November 8.

Current stock supports six units. Ten units require two additional motors and twenty additional valves.

Four engineering and sourcing blockers remain open. These require separate resolution before the build can be cleared within the assessed scope.

If the shortages are ordered on November 2, the recorded lead times indicate material for ten units on November 9—one calendar day after the target. This date is conditional on ordering and on the stated lead times representing usable material arrival.

Overall result: action required.

There are no existing purchase orders in this example. The motor lead time is four calendar days; the valve lead time is seven. November 9 is therefore a conditional replenishment estimate. Purchasing still needs to establish an applicable supply commitment.

The engineering and sourcing findings need their own explanation:

Two additional warnings concern the base plate, which has neither a STEP file nor a drawing, and the controller, which has no recorded lead time. The controller has enough recorded stock for this build, so its missing lead time does not determine the shortage replenishment date.

Morgan now has a specific conversation to lead. Can Jordan secure the missing material earlier? When can Riley resolve the design evidence? Would a six-unit scenario be useful to review?

Reducing the quantity to six would remove the current material shortages. The engineering and sourcing findings would still require attention.

Launch Master: from records to a working review

Launch Master is an application under development at OpenBOM. Its initial purpose is to help a build owner turn product, engineering, sourcing, and material records into a review like this one.

The intended workflow starts with a defined build: product configuration, quantity, material need date, and accountable owner. The team supplies the relevant information, confirms how it relates, and runs the review.

The result would be a Build Gap Report showing material coverage, shortages, engineering and sourcing findings, remaining questions, and next actions. Each finding should lead back to the records supporting it.

The work would continue through assigned tasks and another review after corrections. Riley could update the design reference. Jordan could add the supplier response. Morgan could then see which findings changed and what remains open.

Completing a task would need supporting evidence and a recheck before its underlying finding could close.

Conversation would provide another way to explore the same result: Why are we limited to six units? What makes November 9 conditional? What is Jordan waiting for? The answers should use the reviewed information and expose its assumptions.

What the Engineering Data Harness contributes

We are developing Launch Master as the first application on an Engineering Data Harness. The harness would provide the information foundation for this workflow.

First, it would bring in information through supported routes: existing OpenBOM records, spreadsheets, structured sourcing and inventory data, and supported engineering exports or prepared design records. Files could accompany those records as evidence. The review needs to distinguish interpreted information from an attachment whose contents have not been interpreted.

Second, it would help connect the records. An internal Part Number, a drawing number, and a supplier’s part number can refer to the same Item. The harness could propose those relationships for a person to confirm or correct. Ambiguous matches would remain unresolved until confirmed.

Third, it would support analysis and reporting from that confirmed information. Quantities would come from the selected requirements and stock values. Timing would retain its purchasing assumptions. Engineering checks would identify the specific records and references being compared. AI could help explain the result and prepare a report grounded in those findings.

I explored the role of connected evidence in Could AI Have Found Your Build Blocker?. Here, the practical test is whether that foundation helps Morgan prepare, explain, and update an answer with less manual reconciliation.

Where the first assessment stops

The initial scope is one selected product configuration, quantity, and material need date per review. It focuses on engineering and sourcing alignment and material readiness, using supplied stock and a designated source for each Item.

The reported date means material availability. Manufacturing capacity, routing, process instructions, assembly duration, testing, and shipment timing require further assessment. File and revision checks also have a defined meaning: an assigned CAD reference establishes that evidence is present; geometry and fit require engineering validation.

The build owner retains responsibility for deciding how to proceed.

Broader questions remain open. How should the review follow a supplier commitment after an engineering change? Where should routing and process-sheet information enter? Which coordination tasks deserve support next?

The work across company boundaries discussed in Engineering Change Management Across Company Boundaries is part of that direction. We want experience with actual builds to help determine the next steps.

Bring one build

I would like to work with teams willing to contribute one build and help evaluate the result.

A useful starting point is a product or subsystem with a defined quantity and material need date, an applicable BOM, engineering references, sourcing information, and a stock position. We can agree on the supported inputs together and identify what is missing.

We would work with the people who prepare the answer today: review the records, confirm their relationships, examine the Build Gap Report, and correct or challenge its findings. Then we would rerun the review after an update.

The evaluation should answer practical questions. Are the quantities correct? Are the dates explained well enough to use? Do findings reach the right people? Does the process reduce the effort required to prepare the build meeting?

If your team is doing this work, I would like to compare notes and explore a collaboration. Contact me at oleg@openbom.com with one build you would be willing to discuss.

What can we build, and when—and what does your team have to do today to answer that question?

Best,
Oleg