What you hand us, exactly

A line is one of four things. The product — the single root. An assembly — a level Moduloa physically builds and can test. A phantom — a logical grouping (a fastener kit, a cable set) that is never built or stocked as a unit; the OS blows through it when generating work orders and cost. And a handover part — anything a supplier delivers. The rule that makes this standard unusual: handover parts are black boxes. Nothing nests under one. Your machined housing may have forty internal features and its own supplier BOM — none of that enters this file. We take its exterior geometry, its interfaces, and its acceptance criteria; what is inside it is between you and your supplier. This caps the tree's complexity, keeps your suppliers' IP out of our systems, and is why the whole intake can be validated by software.

Because assembly is staged. If your product X contains a core module Y that we build and test before final assembly, and Y holds a PCBA Z that your supplier delivers — then X is the root, Y is an assembly line under X, and Z is a handover leaf under Y. The levels are our build sequence: subassemblies combine into subassemblies until the product exists. A part sits at the level where we consume it — the seal that gets fitted at final assembly is a child of the product, not of the housing it happens to touch.

Under the surface, every line names its parent, and that reference is the structural authority — a parent pointer either resolves or it does not, which is exactly what autonomous validation needs. The level number you see is derived from it and kept in the file only as a checksum: if the two disagree, the file is corrupt and is rejected. Depth is capped at six levels including the root. Deeper trees are a symptom, not a need — your engineering BOM is leaking into the intake, and the fix is marking subtrees as handover parts or phantoms.

Common practice buries acceptance in drawing notes and purchase-order boilerplate. Here it is typed data on every handover line: each characteristic gets an ID, a feature, a method (visual, gauge, CMM, electrical test, functional test, certificate review), limits, a sampling plan, and a disposition on failure. This is what the drawing's tolerance block was actually for — and once it is data, receiving runs with zero human contact, and the same criteria become quality gates in the execution phase. The format is deliberately QIF-shaped, so it can upgrade to the ISO 23952 ecosystem as measurement tooling matures.

Does this part number exist in your catalogue? Is the submitted revision your current revision? What is your price at these quantity tiers? What is your minimum order quantity? What is your lead time today? Catalogue electronics never wait for an email — they are confirmed machine-to-machine through parts-intelligence APIs first, and only the lines no API covers go to the supplier's stated contact. The answers are attestations, recorded against the line.

Every confirmation runs inside a fixed window. When it closes, the OS returns a deterministic outcome: lines confirmed, or lines named as unconfirmed — with the quote's confidence reduced accordingly and the choice back in your hands: wait, accept the estimate, or swap the supplier. The best-run RFQ processes in industry reach roughly 70% supplier response inside a week; a protocol that hard-failed on silence would deadlock most quotes, and a protocol that escalated to humans would stop being a protocol. Silence is priced, not chased.

If the supplier attests a different current revision than the one you submitted, the line fails with a named exception — REV-MISMATCH — and returns to you. Revision drift between a customer's records and a supplier's records is one of the most common quiet failures in manufacturing, and the standard's answer is to surface it before money moves, not after parts arrive. You resolve it; we never guess.

Every supplier that clears the protocol becomes part of a verified network, and a verified supplier is never a static record: the OS keeps researching it — turnover, headcount, filings, delivery history — continuously current. The step after verification is competition: once a product is taken in, the OS can broadcast the same standardized request to qualified suppliers in the network, over APIs, on the same terms — so competitive prices for your parts arrive as fast as attestations do. Your listed supplier anchors the quote; the network is what makes it sharper over time. Verification is the on-ramp. The network is the asset. And everything a network supplier ships into a hub arrives under the marking requirement — one part, one code, one identity, for everyone.

This is a v0.1 draft, published to be corrected — like the tier model and the scorecard before it. Three risks are named openly. First, the friction bet: every study of RFQ behavior says friction kills conversion, and this standard chooses maximal intake friction deliberately; the wager is that customers who clear the bar are worth more than the volume lost at it. Second, mechanical parts have no pricing API layer — the confirmation protocol works around that by asking the one party who already holds the price, your supplier, and that dependency is why the confidence number exists. Third, the quote's confidence percentage starts as a derived metric — the share of lines confirmed versus estimated, price age, supplier history — and only becomes a calibrated statistical claim once quoted-versus-actual data accumulates. Anything else would be a marketing decimal, and the register would eventually catch us. The register →

Researched against real intake requirements and current standards before writing — key references:

JLCPCB — assembly BOM requirements · PCBWay — SMT ordering guide · Arena — BOM field practice · OpenBOM — parent-child vs indented structure · Arena — phantom BOM semantics · NIST — model-based enterprise program · Quality Magazine — MBD adoption 2026 · QIF / ISO 23952 — quality information framework · 1factory — first-article inspection · CycloneDX / ECMA-424 — the open-schema BOM precedent · CEN/CENELEC — EU DPP standards, July 2026 · Nexar — parts intelligence API · Keelvar — autonomous sourcing state of the art