Provenance by Construction: What "US-Sourced" Should Mean for a Robotics Stack

Provenance by Construction: What “US-Sourced” Should Mean for a Robotics Stack

“US-sourced” gets used loosely. Often it means a certificate collected near the end of a program and a line in a proposal. That version is paperwork, and it breaks the first time someone asks a hard question about a part three tiers down. The useful version is a design decision. You decide at the start what you will and won’t build from, and the system gets built around that choice.

This is an industry-level argument about how to think about sourcing in a robotics stack. It describes a posture, not any particular system.

Two different questions

Defense buyers ask two questions that often get blurred together.

The first is where the parts come from. That’s the provenance question, and the rules behind it are sourcing rules: the NDAA restrictions on components from covered foreign countries, and DFARS clauses such as 252.225-7052, which restricts where certain magnets, tantalum and tungsten can come from. You answer it with a bill of materials you can trace, part by part, back to its origin.

The second is whether the item or its technical data is export-controlled. That’s the ITAR and EAR question, and it turns on what the item is and what it was designed to do. Where its parts came from doesn’t settle it. A part built entirely from domestic components can still be controlled, and a commercial part with a clean domestic BOM can sit outside the ITAR altogether.

Calling a stack “ITAR-compliant” because its supply chain is domestic mixes the two up. Provenance is the claim a component maker can actually stand behind. Export classification is a separate analysis, and it belongs with the technical data, not in the marketing.

Built in or bolted on

Bolted-on provenance treats the design as fixed and asks afterward whether it can pass. You build on the most capable parts available, find out which ones create sourcing exposure, then swap or paper over what you can. It’s reactive. Every decision you didn’t make early comes back later as a problem.

The other approach puts provenance on the requirements list from day one, next to performance and cost. It decides which suppliers you’ll use and how deep you trace. You pick components you can account for, and the traceable path becomes the default, so nobody has to maintain it by hand.

This is the same discipline as treating provenance as a design constraint. You can’t credibly vouch for a component whose origin you can’t establish, and you can’t establish origin after the fact for a part nobody tracked.

Why it matters more as autonomy grows

With a human operator in the loop, a sourcing gap is serious but bounded. As machines take on more of the decisions, more of the system has to be something you can stand behind: the compute, the software, and the actuation that carries those decisions into the physical world. All of it has to be supportable over a long service life without surprises about where its pieces came from.

Traceable provenance doesn’t make a system trustworthy by itself. It’s a precondition. You can’t fully vouch for a machine you can’t trace.

The costs, on purpose

Doing this well costs something, and that’s the point. Building for provenance takes options off the table.

Narrower sourcing. You give up buying the cheapest capable part from wherever it’s made. Some good components are out, and you accept that.

Higher cost. Domestic, traceable sourcing usually costs more than the global low bid. You pay the premium because you want to be able to answer for the result.

More work up front. Settling sourcing early means making architecture and supplier decisions before anything ships. It’s slower at the start, and you don’t have to unwind those choices late.

Less room later. Early constraints do constrain you. In exchange, you don’t discover late in a program that a foundational part created exposure you now have to engineer around.

Those are real costs. The alternative is worse: a capable system that’s hard to support and hard to vouch for, which tends to get expensive at the worst possible time.

None of this makes a system more capable. On a spec sheet it sometimes loses. What it gives you is an honest account of how the thing was built and what you gave up to build it that way. And until a first production build has been checked against its BOM, the honest wording is “designed to” the requirement, not “compliant with” it.

A company decision

These tradeoffs touch sourcing, architecture and cost at once, so provenance can’t be added by a compliance team to someone else’s design. It’s a decision about how the company builds. That pushes you toward owning more of the load-bearing stack instead of assembling it from parts whose sourcing you inherit. When the layers that carry the most trust are ones you designed for traceability, provenance stops being a claim you defend. You can show it.

Sentinel Automata is a U.S. robotics operating company.