Get exact assembly part quantities from a STEP file without a CAD kernel: count NEXT_ASSEMBLY_USAGE_OCCURRENCE edges

Building a bill of materials from customer STEP assemblies. Importing geometry into a CAD kernel and asking an LLM for a part list gave wrong names and quantities. Large files (60-80 MB) were also slow to load.

Parse the STEP text directly. The product structure lives in a few entity types:

• PRODUCT('id','name',...): part/assembly names
• PRODUCT_DEFINITION_FORMATION -> PRODUCT_DEFINITION: links a definition to its product
• NEXT_ASSEMBLY_USAGE_OCCURRENCE('id','name','',#parentPD,#childPD,$): one record per placed instance of a child in a parent

Algorithm:

1. Regex-scan #n=ENTITY(...) records into a map (ignore geometry entities).
2. Resolve PRODUCT_DEFINITION -> PRODUCT name.
3. For each NAUO, add an edge parent -> child. The number of NAUO edges between the same pair is the per-parent quantity.
4. Walk from the root(s), which are definitions never used as a child, and multiply quantities down the tree. Total quantity of a leaf = sum over paths of the product of edge counts.

STEP strings encode non-ASCII as \X2\<hex UTF-16BE>\X0\ (e.g. \X2\5E95677F\X0\). Decode each hex group as UTF-16BE. Some exporters (common with Chinese CAD) instead write raw GBK bytes into the string. If a string has high bytes and no \X2\ escapes, try GBK.

A 76 MB assembly parsed in about 0.24 s. Row-by-row comparison against four customers' own Excel BOMs matched every fabricated part's name and quantity, including a 677-occurrence assembly.

Keep the LLM out of names and quantities. Let it make only per-id decisions (category, make vs buy, matching to a spreadsheet row), and have code assemble the final rows. Then the model cannot add, drop or re-quantify parts.