How a Product Is Manufactured: From Bill of Materials to Production Line

This is Part 3 of Inside the Physical AI Factory. Part 1 mapped the factory. Part 2 mapped the machines. Now we connect product, parts, suppliers, operations, people, and evidence into one route that can produce an accepted unit repeatedly.

A prototype can work even when its manufacturing system does not. An engineer may spend a day adjusting a bracket, replace an unavailable connector, hand route a cable, load software from a laptop, and remember the one unusual calibration step. The finished rover moves. The knowledge required to build it again still lives in the engineer rather than in a controlled production process.

Manufacturing begins when that hidden knowledge becomes explicit. The product needs a released definition. Every item needs an identity, quantity, source, revision, and acceptance requirement. Every operation needs an input, output, sequence, resource, time assumption, and response to failure. The route must produce the same approved configuration without depending on memory or improvisation.

This report builds that system around the hypothetical autonomous inspection rover used throughout the series. We will take it apart, construct a bill of materials, map representative suppliers, choose what to make and buy, write the production route, and compare ten prototypes, the first one hundred commercial units, and capacity for one thousand units per year. All rover specifications, costs, labor times, yields, and volumes are illustrative planning assumptions. They do not describe a real product or supplier relationship.

A three dimensional model may define the geometry of a bracket, but it does not define the complete product. Production also needs materials, finishes, tolerances, purchased part numbers, electrical drawings, cable definitions, software versions, calibration data, labels, packaging, inspection methods, and approved deviations. The build package must answer what to make, what to buy, how the pieces connect, and how acceptance will be proven.

NASA describes approved specifications, drawings, parts lists, and other configuration documentation as the baseline of a product. Its configuration management guidance focuses on keeping the physical product and its information consistent as changes occur. The underlying lesson applies far beyond aerospace. If the drawing says revision C, the work instruction says revision B, and the purchasing system orders the revision A component, the factory does not have one product definition.

The digital thread is the connection among these records. NIST describes it as lifecycle information linking design, manufacturing, quality, and product support. For the rover, a failed camera alignment test should point to the unit serial number, camera lot, bracket revision, fixture version, calibration procedure, result, and corrective action. That chain turns a defect into usable engineering feedback rather than an isolated surprise.

A useful bill of materials follows product structure. The top level rover contains major subassemblies that can be designed, purchased, assembled, inspected, and changed with clear boundaries. Each subassembly then contains lower level parts. This hierarchy helps engineering manage interfaces and helps production decide where work should happen.

The teaching rover uses eight major groups: structure and enclosure, mobility, electrical power, control electronics, perception, communications, cable harnesses, and shipment items. Software and calibration are configuration items even though they are not physical inventory. Fixtures, tools, spare consumables, and factory test equipment belong to the manufacturing system rather than the sellable product bill.

Interfaces deserve special attention because defects collect where subsystems meet. A motor may pass its supplier test while the rover fails because the gearbox ratio, wheel diameter, encoder convention, motor controller settings, cable pinout, and software sign convention do not agree. Product architecture is therefore also an integration plan.

A bill of materials is often introduced as an ingredients list. Production needs more than item names and quantities. Each row should identify the internal part number, description, revision, quantity, unit of measure, make or buy status, approved manufacturer and supplier information, lifecycle risk, lead time assumption, inspection requirement, and the assembly in which the item is consumed.

The engineering bill of materials explains the designed product. The manufacturing bill adds what is needed to build and ship it through the chosen route. A design may show one cable assembly. The manufacturing record may also need labels, tie points, protective sleeving, consumable allowance, test adapters, and the sequence in which branches are installed. Packaging and included accessories belong in the shippable product definition even when they are absent from the engineering model.

IPC's production checklist identifies the bill of materials alongside board data, fabrication notes, assembly notes, drawings, and other engineering documentation. Its design for manufacturing guidance also shows why a board file alone is not enough. The manufacturer must be able to compare the design with process capability before material is committed.

Public catalog examples show how quickly a provisional choice becomes configuration data. Raspberry Pi currently offers Compute Module 5 in multiple memory, storage, and wireless variants, with official product documentation and lifecycle information. Luxonis lists several OAK camera configurations with different optics, enclosures, interfaces, and public prices. Writing only Compute Module or depth camera in a bill of materials would not control what arrives, what fits, or what software image should be loaded.

The make versus buy decision should not begin with the price of one part. It should begin with the capability required to deliver the part repeatedly. Owning a process means owning its equipment, people, safety, quality, maintenance, scheduling, materials, waste, data, and recovery when something fails. Buying the part means owning the specification, supplier selection, incoming evidence, change control, commercial terms, and contingency plan.

For ten rovers, outsourced laser cutting, machining, board assembly, battery packs, and cable fabrication can provide capabilities that would be irrational to build. Internal work can focus on integration, software, fixtures, calibration, and learning. At one hundred units, recurring lead time and quality problems may justify bringing selected harness, fixture, or final assembly work inside. At one thousand units, a stable and heavily used process may justify dedicated equipment, but volume alone does not make every process strategic.

The product boundary matters. A startup can own the design, software, final integration, test records, and customer support while buying nearly every component and fabricated part. That is still a manufacturer if it controls the product configuration and accepts responsibility for the finished result. Outsourcing transfers work. It does not transfer product accountability.

The bill of materials says what belongs in the rover. The routing says how one accepted rover is produced. Each operation should identify the work center, predecessor, standard input, instructions, tools or fixtures, expected time, quality gate, output status, and record created. A route can include outside supplier operations as well as internal work.

The route should follow physical and verification logic. Hidden joints are checked before they are covered. Electrical continuity is tested before expensive electronics are connected. A software image is verified before calibration. Subsystems are tested before final integration when that makes fault isolation cheaper. The final functional test proves the released unit, not just a collection of passing parts.

NASA separates verification from validation. Verification asks whether the product conforms to its requirements. Validation asks whether it performs the intended purpose in the intended environment. A rover can pass dimensional, electrical, software, and braking requirements yet still fail to complete a representative inspection mission. Production acceptance needs both the build requirements and an appropriate operational demonstration.

The first ten units should not pretend to be a mature line. Their purpose is to expose interface errors, difficult assembly steps, weak parts, missing requirements, test gaps, supplier limitations, and the real sequence of work. Flexibility is more valuable than local efficiency because the design is still moving.

Prototype parts may be machined from stock, printed, laser cut, or assembled from development modules. Harnesses may be made on a bench. Engineers may perform most of the integration. That is acceptable only when every workaround becomes visible. Redlines, substitutions, rework, calibration changes, and failures must return to the released definition or be closed before the next build.

The most useful output is not ten matching shells. It is a more complete production package. The team should finish the build with corrected drawings, a structured bill of materials, known supplier questions, preliminary work instructions, repeatable test methods, a defect record, and evidence about which design decisions are ready to freeze.

The first one hundred commercial units create a different problem. Customers now expect consistent configuration and support. Purchasing must place orders before every detail is convenient. Suppliers need forecasts and release packages. Assemblers need work that can be trained. Quality needs defined limits and a way to contain defects without stopping learning.

A pilot cell is usually more appropriate than a rigid line. Benches can be arranged in route order while people flex among kitting, mechanical assembly, electrical assembly, software, calibration, and test. Fixtures become more durable. Torque tools, electrical testers, and software stations capture records automatically where the value is clear. Batch size remains small enough to detect a problem before it spreads across a large inventory position.

This stage should establish the product and process baseline for growth. The manufacturer needs a formal method for engineering changes, supplier deviations, nonconforming material, rework, and software release. A corrected part on unit 37 must not quietly create three different rover configurations by unit 60.

Capacity begins with demand and available production time. In the illustrative case, the plant plans one shift for 250 days per year with 420 net production minutes per day after breaks and planned meetings. One thousand accepted units therefore require an average takt time of 105 net minutes per unit. Takt is the demand pace, not the time required to build one rover.

The assumed route contains 515 minutes of direct work across kitting, structure, mobility, electrical integration, enclosure, programming, calibration, final test, and packing. That work can be divided among stations operating in parallel. The longest assumed station is final test at 100 minutes, which fits inside the 105 minute takt on paper. The line would have theoretical capacity for 1,000 units only if availability, yield, staffing, supply, and changeovers were perfect.

The planning model therefore targets about 1,190 attempted units before losses, then applies an illustrative 84 percent combined allowance for uptime, staffing variation, changeover, and accepted yield. That returns approximately 1,000 accepted units. This is arithmetic for teaching. A real capacity study would use measured cycle distributions, product mix, failure history, shift calendars, material availability, repair loops, maintenance, and simulation where interactions are complex.

Higher volume can reduce purchased part prices, spread tooling and launch work, improve labor through fixtures and training, and lower rework through process control. It can also increase working capital, minimum order commitments, tooling exposure, field liability, and the cost of a design mistake. A lower quoted unit price does not guarantee a lower economic risk.

The following model makes its assumptions visible. It is not a quote, forecast, target margin, or estimate for a real rover. Purchased materials, supplier fabrication, labor rates, labor hours, quality loss, packaging, and launch investment are invented teaching inputs. The purpose is to show how a manufacturing team should structure the calculation and which exclusions can make an attractive unit number misleading.

Public component prices can anchor individual line items but cannot establish the finished bill. Raspberry Pi and Luxonis publish prices for selected compute and camera products. A manufacturer would still need the exact released variants, volume terms, carrier board, cables, thermal solution, duties, freight, inventory, incoming verification, integration, and lifecycle plan. Catalog price is evidence for one item on one date, not a product cost model.

Final inspection cannot economically discover every hidden defect. Quality gates should sit where information is cheapest and corrective action is still possible. A harness is tested before installation. Power polarity is checked before sensitive electronics are connected. Sensor visibility is confirmed before the enclosure closes. Software identity is captured before calibration. The final test then confirms the integrated configuration.

IPC identifies separate expectations for printed boards, soldered assemblies, cable and wire harnesses, and design documentation. The correct standards and acceptance class depend on the actual product and contract. A startup should not copy a standard number into a drawing without understanding the requirements, supplier capability, inspection method, and commercial consequences.

For an industrial mobile platform, safety and compliance planning starts during architecture. UL Solutions notes that automated mobile platform evaluation can involve fire, shock, energy hazards, batteries, object detection, functional safety, payloads, and product integration. The applicable requirements depend on the product, market, use environment, and jurisdiction. Buying a listed component does not automatically certify the integrated rover.

A physical AI product changes in hardware, software, models, data, calibration, and suppliers. A new perception model can alter operating behavior without changing one screw. A replacement camera can fit the same bracket while changing optics, timing, firmware, thermal load, or calibration. A new battery cell can preserve voltage and capacity while changing safety evidence and thermal behavior.

Every proposed change should identify the reason, affected items, compatibility, inventory disposition, tests required, documents updated, units receiving the change, and approval authority. The team also needs an effectivity rule: the change may begin at a named serial number, lot, work order, or service event. Without effectivity, the company knows the new design but not which product exists in the field.

Configuration control does not mean refusing to learn. It means making learning traceable. Engineers should be able to run controlled experiments and urgent corrective changes. Production and service should then know exactly which approved result applies to each unit.

AI tools can help engineers compare requirements with drawings, summarize supplier documents, flag bill of materials gaps, generate draft work instructions, classify defects, search historical failures, propose inspection plans, and analyze cycle data. Vision models can support assembly verification. Simulation and generated test cases can expose interface assumptions before hardware is cut.

The useful boundary is assistance with evidence and decisions, not unreviewed authority over the product. A generated work instruction may omit a safety step. A supplier match may confuse similar part numbers. A vision classifier may fail on a rare defect or new lighting condition. A language model may produce a plausible but nonexistent specification. Released manufacturing data still needs accountable owners, controlled sources, verification, permissions, and change history.

Physical AI also changes the product being manufactured. The rover leaves the line with sensors, compute, models, software, and calibration that determine its actions. Manufacturing must therefore prove both physical construction and configured behavior. The product is not complete when the hardware looks right. It is complete when the approved hardware and software configuration performs safely within the intended operating boundary.

The first mistake is treating the prototype bill as a production bill. Development boards, hand modified parts, substitute connectors, temporary cables, and engineer knowledge can prove a concept without defining a repeatable product. The second is ordering long lead material before interfaces and change exposure are understood.

The third mistake is optimizing purchase price while ignoring tooling, freight, inspection, failures, inventory, and supplier response. The fourth is automating an unstable sequence. Automation repeats ambiguity quickly. The fifth is waiting until final test to discover hidden assembly defects.

The sixth mistake is freezing hardware while allowing software, models, and calibration to change without equivalent configuration discipline. The seventh is confusing one hundred completed units with a capable process. Output becomes evidence only when the team knows the configuration, attempted quantity, accepted quantity, defect pattern, rework, cycle distribution, downtime, and field result.

You should now be able to start with a product architecture, turn it into a controlled bill of materials, connect each item to a make or buy decision, and place every transformation on a production route. You should also be able to distinguish total labor content from takt, a catalog price from finished product cost, and a passing component from a validated integrated rover.

The central idea is simple. A product becomes manufacturable when its design, supply chain, process, quality evidence, software, and change history describe the same approved thing. Volume does not create that discipline. Volume exposes whether it exists.

Part 4 will move beyond the rover and map the industrial ecosystem that makes production possible. We will separate equipment manufacturers, component suppliers, automation platforms, machine builders, distributors, systems integrators, contract manufacturers, engineering firms, contractors, and software providers.

One robot machine tending cell will show who supplies the arm, tooling, safety, controls, vision, fixture, machine interface, programming, installation, acceptance, and ongoing service. The goal is to understand not only what a factory needs, but which kind of company is responsible for delivering each layer.

This report uses NIST digital thread research for the connection among product design, manufacturing, measurement, and lifecycle information. NASA systems engineering guidance supplies the general distinctions among configuration management, product realization, verification, and validation. These practices are adapted as educational manufacturing principles and do not imply that the hypothetical rover follows a NASA program standard.

IPC materials provide the electronics design, documentation, assembly, cable harness, and acceptance context. ASQ provides the definitions of takt time, cycle time, process capability, and standard work. UL Solutions provides general context on the safety evaluation topics that can apply to industrial automated mobile platforms.

Raspberry Pi and Luxonis are representative public component examples. Their specifications, availability statements, and listed prices were accessed September 16, 2026. Maxon is included as a representative robotics motion supplier. No named company is claimed to supply the hypothetical rover, approve this architecture, or validate the illustrative production plan.

Every rover specification, supplier choice, labor time, cost, yield, route, and capacity number in this report is an explicit hypothetical teaching assumption. The material is educational. A real product requires qualified engineering, safety, quality, compliance, cybersecurity, commercial, and legal review for its intended markets and use environments.