A worked example built inside Nexus PLM for a Fictitious firearm suppressor manufacturer -
product line Beans & Bang - carrying a complete audit trail from customer order → federal paperwork → manufactured part → serial number, with the federal documents a real manufacturer has to file.
A new data model for it (documents, items, references, Kanban), the whole process set up and exercised, and the result written up for the Squarespace site, with screenshots taken.
This is all fictious… and was used to stress test the Nexus PLM Systems and Capabilities.
Serialized Manufacturing with a Full Audit Trail
Some manufacturers cannot simply ship a part. Every unit they build is an individually identified, individually regulated article: it carries a serial number an authority reads back years later, it cannot leave the building until one form has been filed and another approved, and the manufacturer must be able to show, for any serial number, what it was built from, who ordered it, and which paperwork covers it.
That is a product lifecycle problem wearing a compliance hat, and it is a demanding test of what a PLM system is actually made of. Most systems can hold a bill of materials. Fewer can tell you, three years later, which released design revision a particular serial number was built to, and show it from both ends.
This walks through the whole thing built end to end on a running Nexus PLM server: the data model, the parts, the assembly, the costs, the customer order, two serialized units, the regulatory filings, and the audit trail that ties them together in both directions. Nothing here is a mock-up or a slide - every screenshot is the product, and every figure was read back from the server.
About the example.
The worked example is a firearm suppressor built under United States federal regulation, because it exercises every constraint at once: per-unit serialization, marking rules, an authority that gates shipment, and a bound record of what came in and what went out. The same model fits any serialized regulated build - medical devices under UDI, aerospace parts with airworthiness release, pressure equipment, or pharmaceutical batches. Where you see an ATF form, read "the filing your regulator requires".
The manufacturer, the serial numbers, the order, the customer, the dealer license number and the control numbers are all invented for this demonstration. The regulatory summary below is background for the data model, not legal advice.
The problem, stated plainly
A suppressor is a silencer under federal law, which makes it an NFA firearm. Three consequences shape the data model.
Each unit is an individual, not a quantity. A part number identifies a design; a serial number identifies one physical object with its own history. "Fifty BB-9s" is not a record anyone can audit. Fifty serial numbers is.
The paperwork gates the product, not the other way round. A unit that has been built and marked still cannot leave the building. The manufacturer files a notice of manufacture with the Bureau of Alcohol, Tobacco, Firearms and Explosives, and a separate transfer application has to be approved before the unit reaches a customer. The unit's lifecycle is therefore a paperwork lifecycle, not an engineering one.
The trail has to run both ways. Given a serial number, produce the design revision, the order and the filings. Given an order or a filing, produce every serial number it covers. A system that can only walk one direction fails an audit from the wrong end.
The rules the model is built around;
Instrument, What it requires , Where it lands in the model and Regulatory Requirements
ATF Form 2 (5320.2)
A licensed manufacturer reports firearms manufactured by the close of the next business day.
Model:
Form 2 object containing:
Filing date
Control number
Reported units
ATF Form 3 (5320.3)
Tax-free transfer between licensees.
Model:
Form 3 object, modeled but unused in this scenario.
ATF Form 4 (5320.4)
Transfer to a non-licensee, with approval required before the unit ships.
Model:
Form 4 object containing:
Transferee
State
Stamp reference
Approval state
27 CFR § 479.102
Requirements for serial numbers, identifying marks, and acquisition/disposition records.
Model:
markingMethod
markingDepthInch
markingsVerified
acquisitionEntryDate
dispositionEntryDate
Special Occupational Tax — Class 2
Status associated with an appropriately licensed manufacturer of NFA firearms.
Model:
filedByLicence on applicable federal forms.
Recent Regulatory Change
Transfer Tax — January 1, 2026
The $200 transfer tax on silencers was reduced to $0 under H.R. 1. The Form 4 and approval requirements remain in place. The model therefore records transferTaxPaid: false for an approved transfer.Export Controls — November 20, 2026
Export control of these articles moves from the State Department's munitions-list regime to Commerce control. The model therefore retains the applicable license reference rather than hard-coding a single regulatory authority.
The data model
Eighteen types, none of them a special case in the platform. Every one derives from an existing abstract base, so the new work inherits attributes, security and revisioning rather than reimplementing them.
Four abstract bases carry the shared behavior:
Manufacturer Item under `ItemsBase` - anything the company designs, with caliber rating, a material specification and a flag for whether the part is the serialized one.
Serialized Unit under `ItemsBase` - one manufactured article, with a build date, the person who built it and the acquisition and disposition dates.
Federal Form under `DocumentsBase` - anything filed with a federal agency, with the filing license, the filing date, the control number, the approval date and examiner notes.
Commercial Record - the customer-facing side, with a customer name and reference.
The concrete types then say only what makes them different: a suppressor assembly has an overall length and a weight, an end cap has a bore diameter, a Form 4 has a transferee and a stamp reference.
The unit's lifecycle is the part worth looking at twice. It is not draft, review, release. It is the sequence the law imposes.
Four link types carry the relationships, and each is a real type rather than a text label; Built To, Ordered On, Filed Under and Certified By.
Because a link is a type, it can be reasoned about - you can ask what a unit was built to without parsing a string, and a link carries its own revision rule. Finally, each type declares what a new revision carries forward. The primary file always carries; everything else is a filter, and an empty filter means everything carries.
The product
The BB-9 is an outer tube, an inner tube, a front cap, a rear cap, a mount adapter and ten baffles. The outer tube is the serialized component: it is the part that carries the serial number, so it is the part the law treats as the firearm.
The structure is where a real assembly starts to bite. There is one baffle part and ten baffles in the product. They are not a quantity of ten on one line; they are ten occurrences, each with its own instance name and its own position down the bore, which is how the assembly arrives from CAD and how it has to be costed, drawn and inspected.
Read from the other end, the single baffle part knows all ten places it sits.
Each part is linked to a material from the library rather than carrying a copied text field. The link resolves by rule, so a material revised tomorrow is still the same link.
With material, labor and overhead on every part, the cost rolls up the structure. The ten baffle occurrences are counted ten times, which is the entire point of modelling them as occurrences: one baffle at $12.00 becomes $120.00 of the $377.65 unit cost.
The job
One folder holds everything: the released design, the customer order, the two units built against it, the federal filings, and the compliance tasks that track them.
It starts with an order from a dealer, recorded with the dealer's federal firearms license number, because that number decides which transfer form applies later.
Two units are built and serialized. The serial number is the part number, allocated by the server from a numbering schema, so a serial can never be typed twice or skipped.
The manufacturing notice is filed the next day, covering both units.
One unit is then transferred to the customer on an approved Form 4. The second stays in inventory, which is exactly the state a real shop is in most of the time.
The work itself runs on a board whose columns are the real stages, from order received through to shipped.
The audit trail
This is the part that matters. Open serial number BB-2026-00001 and every link is there: the design revision it was built to, the order it came from, and both forms it was filed under.
Each edge carries its own type and its own revision rule. Built To resolves to the latest released revision of the assembly, because a unit is built to a released design. Ordered On resolves to the latest revision of the order, because an order can be amended and the unit should follow it.
Now read it backwards, which is the direction an auditor arrives from. Open the order and it lists both serial numbers built against it and where each one currently is: one transferred, one still in inventory.
The same relationships drawn as a graph, from the assembly outward: its parts, the baffle counted ten times, and the two units that reference it.
Nothing above is a report that was written for this scenario. Every view is the platform's own, reading the same links from both ends.
What we learned about the platform
The scenario was built to find gaps, and it found five. All were logged, and the most serious was fixed and deployed the same day — which is the honest reason to publish this section rather than quietly omit it.
A revision save destroyed its material link - found and fixed (NI-00000195).
The material link is stored as a JSON object inside the revision's extension data. Every update stamps a modified-by field, and that stamp round-tripped the whole blob through a dictionary that could hold strings, numbers and Booleans but not objects — so the link was read back as null and written out as null. Two hundred OK responses, no error, and the link gone. It surfaced here because materials and costs were set by the same script, the cost write landing second, and it affected any save of a revision carrying a material link, from the client too.
The fix keeps non-scalar values through that round trip, so every future entry of the kind is safe by construction rather than by convention. Eleven tests cover it, seven of which fail without the change.
A folder view kept a stale list after a membership change (NI-00000191).
Worth including because the first diagnosis was wrong, and checking it changed the answer. It looked as though a user added to a project kept their old visibility until their session expired. A probe settled it: a user was issued a token, a project and an object were created afterwards, the user was added, and that same untouched token went from refused to allowed with no re-login. Access is evaluated live on every request — which also means a removal takes effect at once, the direction that matters. What was stale was one view in the browser, redrawing from what it already held.
Listing every object has no paging (NI-00000192).
Against 2,154 objects the call takes about four seconds, while every other call measured in the same run was under a tenth of a second. It is the one call whose cost grows without limit as real data lands.
A board can only bind an issue type (NI-00000193).
Boards bind types derived from the issue base, so the serialized units could not go on a board directly. The scenario had to model a separate compliance task per unit that references the unit, which duplicates state across two objects. Worth deciding whether any type with a lifecycle should be able to run across a board.
Projects is a user app made of administration (NI-00000194).
Membership, privileges and ownership sit in the main navigation for every user. Set against that, the things that simply worked are worth naming: eighteen new types created through the API with no restart, a numbering schema producing serial numbers that cannot collide, ten occurrences of one part costed correctly, typed links resolving by rule in both directions, and a graph view that needed no configuration to draw a domain it had never seen.