An IoT bill of materials should preserve integration knowledge
An IoT bill of materials answers what to buy: part numbers, quantities, sometimes prices. That is also why it often fails the next team. A BOM on its own does not say why a component was chosen, which documentation governed the selection, what was actually tested, or what may replace it. It stays useful for integration and maintenance only when the purchasing view is connected to a versioned integration record.
Record exact identity, not just a category
For each component, record the exact part and revision, the function it was selected for, and the documentation used to decide. This matters because manufacturers revise and discontinue parts: Texas Instruments, for example, states its product life cycles are typically 10 to 15 years and often extend longer, and publishes lifecycle statuses — preview, active, not recommended for new designs (NRND), last time buy and obsolete — so buyers can plan (TI product life cycle). Availability also differs by part; Raspberry Pi, for example, states that the Raspberry Pi 5 will remain in production until at least January 2036 (Raspberry Pi 5 product page). So record the identity you actually selected, and check the current lifecycle status when the BOM is used, not only when it was written.
Separate what each document proves
A manufacturer datasheet, a supplier quotation and installation evidence answer different questions. Keep them distinguishable from the component entry: the specification supports selection, an offer supports purchasing, and only tests on real hardware support the claim that a component works in your system. A quotation is not installation evidence, and a bench check on one node is not site commissioning.
Keep quantities answering different questions
Design quantity, explicit spares and purchasable pack quantities are three different numbers. Keep them separate instead of folding rounding into the engineering requirement, and obtain actual supplier terms rather than guessing missing pack sizes.
Make replacement constraints visible
Sooner or later someone proposes a similar-looking substitute. Before that happens, the record should show what must be compared: the actual interface, electrical requirements, behaviour and installation conditions. A matching category is not equivalence — verify before substituting. When a component does change, create a reviewed revision of the configuration and record which evidence must be repeated, instead of quietly rewriting history.
From shopping list to handover tool
Most of this is discipline rather than tooling: a link from each entry to its evidence, and a rule that changes create new versions. Keeping that record current is where the ongoing effort goes. This is where MIND AIoT is built to help: the platform and its agents maintain live documentation — bill of materials, features, requirements and user instructions — as a built-in capability, and Manna-configured agent workflows include component document analysis, driver and library retention, and BOM maintenance. These workflows do not remove hardware verification, and they do not make the record complete on their own.
If you are deciding how your own BOM should preserve integration knowledge, the MIND AIoT platform page describes the platform and licensing model at principle level.
Prepared with AI assistance for Manna Insect Oy.