Engineering
On-device by design: why SENTINEL never sees your files
The lazy way to build a firearm-blueprint filter is a cloud API: upload the mesh, score it on a server, return a verdict. It's easier to ship, easier to update, easier to demo. We rejected it on day one, for three reasons that get more important the longer you think about them.
1. A cloud filter is a surveillance system with extra steps
If every print job routes through someone's server, you've built a registry of everything everyone makes — prototypes under NDA, patent-pending parts, personal projects. Nobody should have to choose between complying with the law and disclosing their IP to a third party. On-device screening dissolves the dilemma: the file is evaluated where it already is, and it never leaves.
2. Printers live offline
Print farms firewall their machines. Schools run air-gapped labs. Hobbyists print from SD cards in garages with no Wi-Fi. A blocking layer that fails open when the network is down is a loophole, and one that fails closed is a bricked printer. The statute's own definition — integrated technological measures — points the same direction: the capability has to live in the machine.
3. Circumvention resistance requires integration
AB 2047 expects safeguards that hold up against technically skilled users, and makes bypassing them a misdemeanor. A cloud call is trivially blocked at the router. A screening layer bound to the motion planner in firmware, with signed signature packs and tamper-evident logging, is a fundamentally harder thing to route around.
Privacy isn't a feature we added to the detection layer. It's the shape the detection layer had to take to be any good.
The hard part
The cost of this architecture is honest engineering: models small enough for printer-class hardware, evaluation harnesses that measure false positives and false negatives the way a regulator would, and an update path that works from a USB stick. That's the work. We think it's the only version of this product worth building.