On September 29, I was walking the floor at NADCA's Die Casting Congress & Tabletop in Grand Rapids.

The show floor at NADCA's Die Casting Congress & Tabletop, DeVos Place, Grand Rapids, September 29.

Somewhere along the way I passed a booth doing industrial AI, and that caught my attention right away. The person standing there was Chinese, so naturally I walked over and started talking.

We had never met. It was just booth small talk, until it turned to a project from a few years back: the quality inspection system we built at Tesla. That got us going. The names he mentioned, I knew. A few minutes later we found people we both knew.

What surprised me more was how well he knew that project. How we built it, how we validated it, how the validation actually landed on the production line. I only had to start a sentence and he finished it. Running into someone at a trade show who knows your project that well is a strange and nice feeling.

Why they had been paying attention isn't hard to see. At Tesla, his team did data analysis, which in practice meant quality prediction and parameter recommendation. If our inspection worked well, quality data for every single part could flow into their system. For people doing analysis, that's more data, and much finer data. So they kept watching.

What they're doing now

The team later left to start a company, IndustrialMind.ai, founded by former Tesla manufacturing AI people. The person I talked to was Jeff Wang, the company's chief AI engineer. Before this he worked on AI-driven production optimization at Tesla and GM, and gigacasting is home ground for him. In October 2025 the company announced a $1.2 million pre-seed round.

They call the product the "AI Engineer." After the show I went through their public material, and the scope is much wider than what I heard at the booth.

The first half is engineering. It reads drawings, reviews them against the customer's internal standards, extracts features, and drafts BOMs, routings and cost quotes. When a new part comes in, it checks it against existing products so whatever can be reused gets reused.

The second half is production. It monitors in real time and predicts anomalies. When a quality problem shows up, it runs root cause analysis, correlating quality data with thousands of process parameters. Then it recommends parameter changes and validates them on the actual equipment.

The die casting parameters Jeff talked about at the booth sit in that second half. He said there are over a hundred of them: the machine's own settings, die temperature, and plenty more, all pulling on each other. Finding good settings used to mean people writing rule after rule by hand, which was painful. Now AI can do the wiring, and the whole thing gets built quickly.

One public deployment is ANDRITZ. In March, the two companies announced three agents running on hydraulic equipment parts: drawing review, BOM generation and root cause analysis. Early observations, in their words, point to drawing review time coming down by up to 30%. On the die casting side, Jeff said several plants in Europe, the US and APAC are already live, and the customers have been genuinely impressed. He didn't go into detail, so I won't either.

Why now

What I agreed with most was that they're doing this with the newest agents, and doing it the way a forward-deployed engineering team does: one industry at a time, inside each plant's existing workflow, instead of selling a platform and leaving the customer to integrate it.

The thing I think they do best is capturing what's in engineers' heads. Their ANDRITZ announcement describes it as turning engineering know-how into standardized, reusable digital workflows. In engineering terms, that's the harness layer: which data to connect (drawings, specs, MES, machine data), what standard to judge against, which step needs a human signature, and how to trace an error. Once that layer is built, an agent can be trusted to run.

Then there's the shape of the product in front of the customer. They don't hand over one big platform. They hand over one agent per workflow: one for drawing review, one for BOMs, one for root cause analysis. Engineers don't learn a new system. They get a helper. Their CEO put it this way in the announcement: "The biggest barrier to AI in manufacturing isn't the technology, it's knowing which workflows are actually worth automating."

Why was this hard before? The algorithms were never the problem. The problem was that every plant has different machines, protocols, data formats and internal standards, so every new plant was a custom job, and the custom work ate the margin. Now much of the wiring and cleanup can go to agents. People build the harness and encode the industry's know-how into it, and the cost of bringing on a plant drops. That's what makes this a business now.

Where it sits on the map

I've drawn a map before. The horizontal axis is the cost of failure, the vertical axis is the cost of verification. Automation happens first in the corner where both are low.

Put their product line on that map and something interesting shows up: it lines up almost exactly along the verification-cost axis.

Drawing review and BOMs sit at the cheap end. The agent produces a document. An engineer can read it, fix it and sign it in minutes, and if it's wrong, it's only a draft. It's also where the first public number came from: the ANDRITZ 30%.

Root cause analysis is one step up. The agent says this batch of defects comes from die temperature drift. How do you know it's right? You make the change and wait to see whether the defects actually go down.

Parameter recommendation, validated on real equipment, sits at the expensive end. To judge a set of parameters, you need to know the quality of every part made with them. Without per-part inspection, verification means sampling and tracing back after the fact. You find out days later whether the settings were good, and even then it may not be clear. In that world an agent can only recommend cautiously. With inspection on every part, and every part's defect distribution recorded, verification comes down to a single image. You know by the next shot.

That's where I think our inspection and their system fit together. Inspection gives the defect distribution for every part: what kind of defect, where, how big, and how it drifts from batch to batch. Nobody can hold that in their head. I've written before that veteran operators compensate for die drift by hand every day, and nobody records how much. When the shift ends, it's gone. Per-part inspection records exactly that missing ledger.

Feed that data in and their system can go a lot further.

There's one more layer. An agent that recommends parameters can't be the one who judges whether its own recommendations are right. The builder can't be the verifier. Inspection stands outside the recommendation, a referee the agent doesn't control. If parameter recommendation is going to make it onto real production lines, sooner or later it needs a referee like that.

Looking ahead

They're already working across several industries: die casting, other kinds of casting, and more. Die casting has the most deployments. The others are just getting started.

What follows is my own inference, not something Jeff said. Once they've gone through enough industries, the wiring, the harness and the domain knowledge they've built up could grow into an operating system for industry. Each new industry would need less built from scratch.

Die casting is a good place to start. Lots of parameters, tangled together, expensive quality problems, and veteran know-how that's hard to pass on. Put those together and you get exactly the place where an agent can help most, and prove itself fastest.

That day was the first time we met. I do inspection, they do analysis, and someday the two might connect. Even if they never do, I think they're standing in the right place. In this wave of AI, connecting and analyzing manufacturing data is exactly what agents can reach today, and they've done the homework.

If you know a process engineer at a die casting plant who still tunes die temperature by feel, send them this.

A chance meeting at a die casting trade show turns into a bigger question: which jobs in a factory will AI agents take over first, and what decides the order? Why decades-old process analytics is suddenly a real business, a simple ladder that predicts which AI tools land first, and the most valuable data in a plant that almost nobody records.

Read the full article: At a Die Casting Show, I Ran Into Someone Who Had Already Seen Our Data

Voices are AI-generated. The analysis and every number come from the original article by Yuanwei Ma.

Chapters

• 0:00 Intro: a stranger who already knew the project

• 1:28 Why inspection data matters to AI

• 2:38 What is die casting? 100+ parameters

• 3:41 Why now? The math was never the problem

• 5:18 Which factory tasks will AI agents automate first?

• 6:33 Why can't an AI verify its own work?

• 7:49 What to take away, and what's next

Transcript

Welcome in. Today we're breaking down a short field report from a newsletter called First Principles Manufacturing. It covers AI, robotics, manufacturing and the US–China angle, written by an engineer who builds this stuff for factories. And this one starts at a die casting trade show in Michigan, with a chance conversation. But it ends up answering a much bigger question: which jobs in a factory will AI actually take over first, and what decides the order. So who should stick around?

If you invest in industrial tech, if you run a plant or manage a line, if you know your own corner of manufacturing really well but haven't seen the whole picture, or if you're thinking about getting into this industry, there's something specific in here for you. Three things, actually. Why a kind of factory software that's been possible for decades is suddenly a real business. A simple ladder that predicts which AI tools land first. And the most valuable data in your plant, which almost nobody records. Quick note before we start: our two voices are AI-generated. Every fact we use comes from the original article, linked below. Okay, Ben. The trade show.

The author is walking the floor, stops at a booth doing industrial AI, starts chatting with a stranger. And within minutes, the stranger is describing a project the author's team built years earlier. Not just what it was. How they tested it. How they proved it worked on a real production line. Wait, how would a stranger know that? That's the hook, and the answer is kind of beautiful. The stranger had seen the data. The author's team had published their inspection results openly, and the data spoke for itself. So this episode is really about what happens when you put real numbers out in the open.

Here's the thing about die casting. It's one of the oldest high-volume manufacturing processes on earth. You inject molten metal into a steel mold under enormous pressure, it cools, you pop the part out. Engine blocks, transmission cases, the stuff cars are made of. And the quality problem is brutal. Porosity, cold shuts, misruns. Defects that hide inside the metal where you can't see them. Traditionally you find them with X-ray, which is slow and expensive, or you find them when the part fails. Neither is great.

So the question this episode asks: when AI comes for factory jobs, which ones go first? The answer isn't “the easiest ones.” It's the ones where three things line up. First, the data already exists or is cheap to collect. Second, the cost of being wrong is manageable, or the system fails safe. Third, somebody has already proven it works somewhere, so the next buyer isn't gambling. Die casting inspection hits all three. The data is images, which are cheap. A false alarm costs a manual recheck, not a scrapped engine. And the results were published openly, so the next plant manager can see the numbers before buying.

Compare that to, say, robotic welding of structural joints. The data is harder. The cost of being wrong is a failed weld in a car frame. Nobody wants to be first. So welding waits, inspection goes first. That's the ladder. Data availability, failure cost, proof of precedent. Run any factory task through those three and you can predict where AI lands next.

There's a second thread here about the most valuable data in your plant. It's not the sensor streams or the MES logs. It's the stuff nobody records. The operator who knows that a particular mold runs hot on humid days. The maintenance tech who can hear a bearing going bad two weeks before it fails. Tacit knowledge, walking out the door every evening. The plants that figure out how to capture that, even partially, will have an advantage that no algorithm can copy quickly.

So the takeaway in three lines. One, AI takes factory jobs in a predictable order: data-rich, low-failure-cost, proven tasks first. Two, open data accelerates adoption more than better algorithms. Three, the scarcest data in manufacturing is the knowledge in people's heads. Thanks for listening. If this was useful, share it with someone who runs a plant.

On September 1, OpenAI launched a batch of agents. On the order of ten thousand of them, running at once, split into groups, each group working a different variant of the Navier–Stokes problem.

Eighty-eight hours later, on September 5, they returned a result: a fluid starting at rest, pushed by a smooth external force, winds into a vortex that spirals inward while stretching along its axis, and its speed goes to infinity in finite time. The equations blow up. Seventeen hours after that, the proof had been translated into Lean and checked by machine, line by line. According to press accounts, this one problem consumed about 130 billion output tokens.

OpenAI announced it at noon on September 8. Navier–Stokes is one of the seven Millennium Prize Problems the Clay Mathematics Institute posted in 2000, each carrying a million-dollar prize. If the result survives peer review, it will be the second of the seven ever solved. The first was the Poincaré conjecture.

About twelve hours before the announcement, NYU mathematician Tristan Buckmaster put out a statement of his own. All summer, Buckmaster and Levent Alpöge — an Anthropic employee, working in a personal capacity — had been using AI on a simpler cousin of the problem, the Euler equations with an external force, following the "forcing" approach developed by Diego Córdoba and collaborators. They had a result in mid-August and had it verified in Lean before the end of the month. Buckmaster's account is that OpenAI learned of their progress days earlier and used the same route.

OpenAI's own write-up tells a different story. On September 1, it heard rumors that two Millennium Problems had been solved, and launched a project to throw agents at all the unsolved ones. Along the way, roughly a hundred agents working for about fifty hours solved an "easier" problem: the Euler equations blow up even without an external force. Seeing that, OpenAI judged Navier–Stokes the most promising target, moved agents over from the other problems, and used the Euler solution as the prompt. It says it never saw Buckmaster and Alpöge's work before they made it public, credits them with priority on the forced Euler result, and says the two proofs differ substantially.

A few days before all this, on September 4, Anthropic had published a result of its own. In eleven days, Claude produced a complete formalization of Fermat's Last Theorem in Lean: 13 million lines of code, more than five times the size of Mathlib, the community's entire library of formalized mathematics, with over thirty thousand intermediate theorems proved along the way. This was a community project Kevin Buzzard of Imperial College London kicked off in 2024, expected to take years. The mathematical input from humans was limited to occasional high-level instructions from the project lead.

On September 11, twenty-five Fields Medalists published a joint declaration titled "A Severe Misalignment of AI in Mathematics." One sentence in it: "solving problems is only a tool and proxy for achieving the primary goal of conceptual understanding and insight."

Four lanes over five weeks. Machines did the search; people decided where to aim. Sources: Anthropic's two research posts; OpenAI's announcement (September 8, updated September 10); Buckmaster and Alpöge's August dates and the "about twelve hours earlier" via the Wikipedia article on the priority controversy; the declaration text on Terence Tao's blog. The hour the OpenAI run started is not public.

For the rest of September, the question in that world was some version of: is math over?

My answer: math isn't over. What's over is the part of math that has a fixed finish line and a cheap judge. And this re-sorting isn't only happening in math. It's happening in every trade at once, including the shop floor.

1. Who did what in those 88 hours

Take the two stories apart and ask what the machines did and what the people did.

The machines did the heavy lifting. Ten thousand agents, over a hundred billion tokens, eighty-eight hours of trying without a break. Thirteen million lines of Lean in eleven days. Search at that scale is more than the entire community of human mathematicians could do in decades.

The people did two other things.

First, they set the finish line. The statement of the Navier–Stokes problem was fixed by the Clay Institute in 2000, every word precise. The proof of Fermat's Last Theorem was given by Andrew Wiles three decades ago; formalizing it means translating something already known. Before either job started, what "done" looked like was perfectly clear.

Second, they picked the direction. Where the technical stepping stone came from is disputed: Buckmaster says the route was theirs first; OpenAI says its own agents found the unforced Euler blowup. Peer review will have to settle that. But one thing isn't in dispute on either side: people decided where to aim. The project started because of a rumor. Putting ten thousand agents on Navier–Stokes was OpenAI's call after looking at the Euler result — its write-up says it concluded Navier–Stokes was the most promising place for a breakthrough. And the stepping stone itself — do the Euler equations blow up? — was also a problem with a pre-written statement and a Lean check.

There's one more role in both stories, and in neither is it played by a person: the judge. Lean is a proof checker. It goes line by line; right is right and wrong is wrong. Each ruling costs almost nothing.

A fixed finish line and a cheap judge. Once both are in place, what remains is heavy lifting — and heavy lifting is exactly what machines are best at right now.

In that sense — and only in that sense — the Millennium Problem was the easy part. The hard parts had been done before the first agent launched: someone wrote the statement, someone built the checker, someone decided where to aim.

2. Two kinds of work: capped and open

Generalize that, and nearly all work sorts roughly into two kinds.

Capped work: you know in advance what "done" looks like, and there's a cheap judge that can tell you whether you got there. A school essay has a rubric. A support ticket is resolved or it isn't. 3D part localization is off by some number of millimeters. Formalizing Fermat has Lean. Even Navier–Stokes, once its statement is fixed and Lean can check the proof, falls on this side.

Open work: you have to define the finish line yourself. Which question to ask; which of dozens of routes is worth walking; what counts as "understanding"; what the tolerance on a part should be, and what "clean" actually means. None of these come with a judge. Put differently: whoever does the work is the judge.

AI acts on these two kinds of work differently.

On capped work, AI is addition. It pushes everyone some distance toward the ceiling, and because the ceiling is fixed, the people farthest from it move the most. Economics has a clean piece of evidence here. Erik Brynjolfsson, Danielle Li and Lindsey Raymond studied 5,179 customer-support agents given a generative-AI assistant. Issues resolved per hour rose 14% on average and 34% for novice and low-skilled workers, with minimal effect on the most experienced. The gap compressed.

Support work has a finish line and a judge, so AI acts as addition: the people farthest from the ceiling gain the most. Data: Brynjolfsson, Li & Raymond, "Generative AI at Work," Quarterly Journal of Economics, 2025. "Minimal" is the paper's word; the bar is drawn near zero.

On open work, AI is multiplication. There's no ceiling, so what AI amplifies is the judgment you already have. The larger the base, the larger the absolute gain.

I find it easiest to think about this with basketball. This is an analogy, not a statistic. Over the past decade, NBA role players have been pulled close to the stars: everyone shoots threes, everyone switches on defense, the floor of basic skill has risen across the league. Yet the stars have pulled further away. Part of the game is capped — shooting form, defensive positioning; once you've drilled it, you've drilled it. Part of it is open — reading the game, deciding who gets the ball in the last two minutes. The first part gets flattened. The second gets stretched.

The economist Sherwin Rosen described the same mechanism in 1981 in "The Economics of Superstars": when technology widens one person's reach, small differences in talent turn into large differences in reward.

Mathematics supplied a direct example this year. Mehtaab Sawhney, an assistant professor at Columbia, took leave to join OpenAI, and with colleagues has used internal models to settle a string of Erdős problems. When Sawhney joined, OpenAI's chief research officer Mark Chen wrote that "accelerating Mehtaab will also meaningfully accelerate mathematics."

Nobody says that about a support agent.

Read the Fields Medalists' declaration again and you'll see they drew the same line I'm drawing. Solving problems is the proxy; understanding is the point. Solving is capped. Understanding is open. AI is eating the first.

3. Where the stars are scarce

If the top gets stretched, what exactly is scarce about the people at the top?

Not the ability to prove things. September showed that as long as the statement is fixed and the judge is present, a proof can be ground out by ten thousand agents.

The scarcity is in two things: picking the direction and being the judge.

Picking the direction is research taste. In September, direction got a very concrete price tag: a rumor that two Millennium Problems had fallen — no names, no methods — was enough for a company to launch a project that ended with ten thousand agents on a single problem. The bare signal that a direction can be walked was worth that much.

Being the judge is subtler. In capped work, the judge comes ready-made — Lean, a rubric, a caliper. In open work there is no ready-made judge, so the person who can say "this result is right, this one matters, this one is worth pursuing" becomes the scarcest part of the whole system.

It's the same structure as my August piece, "The Builder Cannot Be the Verifier." As generation gets cheaper, verification gets more valuable. That piece was about robot programs. This one is about people: once AI makes generation nearly free, human value concentrates at the judgment end.

There's one more layer. In a guest post on Terence Tao's blog, the philosophers Silvia De Toffoli and Eamon Duede put it plainly: the machine delivered an answer, a conclusion checked to be true; mathematicians want a solution, which includes why it's true. They quote the Clay Institute's own explanation of why a proof matters for Navier–Stokes: "Because a proof gives not only certitude, but also understanding." A hundred and thirty billion tokens bought certainty. Understanding is a separate bill. NPR's headline on September 22 was blunter: "AI solved one of math's hardest problems. Humanity learned nothing (so far)."

4. Where the basketball analogy breaks: the ball

At this point I have to admit the analogy has a big hole in it.

In the NBA, the stars and the bench play with the same ball. At the frontier of mathematics, they don't.

Press estimates put the compute for OpenAI's push in the millions of dollars. An independent mathematician without access to that kind of compute, however good their taste, cannot run a route to the end in eighty-eight hours. Meanwhile a researcher with ordinary taste who happens to sit inside a lab might get there first.

That's precisely MIT Technology Review's worry: that mathematics becomes the private preserve of well-capitalized AI companies. The declaration's complaints — results announced in a rush, no time for a proper write-up, prior work left uncited, "severe attribution and plagiarism questions" — connect to the same thing. Access to compute is concentrated in a few companies, and the scarcity may be captured by institutions instead of staying with people.

So the more accurate statement is: scarcity at the top is person × access — the person, times a channel to the compute.

Countries are building that channel differently. In the US, in September, it looked company-driven: OpenAI launched its push on a rumor that someone else had gotten there first, and the whole thing was a race.

China is on a different road.

Two things are on the public record. The State Council's "AI+" action plan, issued in August 2025, lists six priority actions, and the first is "AI + science and technology." In late August this year, Beijing's Zhongguancun hosted a national AI-for-Science conference chaired by fifteen members of the Chinese Academies, with the stated goal of moving research from "people using AI to compute" to "AI conducting research autonomously." And from where I sit, I see more AI-for-Science conferences being convened, and, in manufacturing, companies closing technical gaps quickly.

On one side, a handful of companies build the channel with capital. On the other, the state lays it down by plan. Which road grows more person × access combinations is not visible yet. But the question is worth writing down. It will be one of the most important questions on the US–China line for the next several years.

5. The frontier's other direction: down

Everything so far has been about moving up — essay, code, research, top research. Each step up, the finish line gets blurrier and AI finds it harder to flatten.

But the frontier doesn't only run up. It also runs down.

Down is the physical world: where the part is sitting, where the burr is, whether there's porosity inside the weld. The difficulty there isn't abstraction. It's that you have to touch the thing to know.

The same re-sorting is happening along this line too.

In my piece on Cognex and RealSense, I wrote about Inbolt, a Paris startup I kept running into at IMTS. A standard 3D camera costing a few hundred dollars, plus Inbolt's software, does bin picking and part localization on a robot arm. By the company's own numbers, it has more than 200 systems installed in more than 75 factories, with 0.5–0.7 mm repeatability on a standard camera. Three days after the show closed, Cognex announced it would buy RealSense, the company behind the camera in Inbolt's public demos, for about $500 million in cash.

3D localization got good because it's capped. The part's true pose is right there; millimeters of error make a cheap judge. A finish line plus a judge means it can be flattened. And the result of flattening is that it stops being a craft and becomes a module you can buy.

So where did the value go? To the next place that doesn't have a cheap judge yet.

Deburring is one. After the robot finishes, in most shops "is it clean?" is still answered by a veteran running a gloved hand over the part. Welds are another: you can photograph the bead, but porosity inside takes NDT, which is slow and expensive. Sub-millimeter precision assembly is worse still: what you can measure is often not the quantity you actually care about.

What these processes share is that the finish line hasn't been written down and the judge hasn't been built.

In "Engineering the Map" I argued that where a process sits on the automation map isn't fixed: hang an independent re-inspection behind it, and the cost of verification drops from a veteran's glove to a single image. In today's framing, what that means becomes clearer. Building a judge drags a process from the open side to the capped side. Once it's across, it gets flattened, and the value moves on to the next place without a judge.

That road doesn't end. Every judge you build moves the frontier down one more notch.

Two axes. Horizontal: is "done" defined in advance? Vertical: what does one judgment cost? Bottom-left is capped; top-right is open. Even a Millennium Problem, once the statement is fixed and Lean can check it, sits bottom-left. The arrow is Section 5: hang an independent camera re-check on deburring, and it gets dragged from the middle to the capped side. Positions are qualitative — my judgment, no units.

6. Three things for people who make things

First, ask two questions about the work in front of you. Do you know in advance what "done" looks like? Who judges it, and what does one judgment cost? If both have clear answers, that work is on the side being flattened. Hand it to AI early and move your people off it; don't staff up on it.

Second, the most valuable seat is the person who builds the judge. The one who sets the tolerance. The one who designs the independent re-check. The one who turns "a veteran runs a glove over it" into a judgment you can record and replay. In mathematics this is called research taste; on the shop floor it's called process knowledge. It's open work, so it gets stretched.

Third, access doesn't only live in data centers. In mathematics, access means ten thousand agents, and most people can't get it. In manufacturing, much of the access is physical: cameras, probes, NDT equipment, the line itself. The people standing on the line already hold part of the channel. It's one of the few structural advantages people who make things have in this round of re-sorting. Don't give it away.

One falsifiable marker, for the record: if, in the next twelve months, an AI poses a new problem or a new theory — with no human having supplied the statement or the route — and the mathematical community accepts it as important, then this piece's claim that the open side belongs to people needs revising.

If you know a grad student who spent September wondering whether their field is "over" — send them this.

Subscribe now

I was impressed. The first thing that went through my head was: could this do deburring?

The second time was at FANUC's booth. I didn't expect it there. FANUC, one of the biggest robot makers in the world, on its own stand, running vision from a startup. (FANUC's show release describes a CRX-20iA/L tightening bolts on moving parts.) That's when I started to get suspicious. Is it really that good?

The third time was at a booth doing CNC machine tending. Inbolt again.

IMTS 2026 in Chicago, in front of the show's 100-year timeline, 1927 to 2027.

That was last week at IMTS in Chicago. After the third encounter I had two questions. How is it that accurate? And how is it everywhere?

How is it that accurate?

When I got home I looked up how it works. Inbolt is a Paris startup that does real-time vision guidance for robots. Its technical overview is plain about the method: the software matches the part's CAD model against the 3D data from the camera, computes the part's position and orientation, and corrects the robot's path in real time. First it finds the part in the scene, which Inbolt says takes 200 ms. Then it switches to tracking, with position updates up to 500 Hz depending on the robot brand. Inbolt also stresses that the software isn't tied to any particular camera.

Then I looked at the camera. At Hannover Messe this April, Inbolt's public demo ran on a RealSense D435. The RealSense online store lists that camera at $314.

Every depth point from a $314 camera is noisy. So where does 1 mm come from? From the drawing. The CAD file already says exactly what the part looks like. Fit the whole shape against a large cloud of noisy points and most of the noise averages out in one fit. Inbolt saves money on the camera by leaning on information the drawing already holds.

That also answered the question I had at the booth. Deburring is about finding exactly the places where the part differs from the CAD. A whole-part matching algorithm treats those small local deviations as noise and throws them away. It can tell the robot where the part is. It can't see where the burr is. Inbolt's own spec sheet agrees: repeatability with the standard camera is 0.5 to 0.7 mm, and to get under 0.3 mm you switch to its separate high-precision structured-light camera. For picking, bolting and dispensing, the standard camera is enough. Deburring needs a different kind of measurement.

How is it everywhere?

The answer to the second question is in what Inbolt doesn't build.

It doesn't build cameras. When it raised its Series A in September 2024, Inbolt already described itself as "software-only," working with "any standard 3D camera."

It doesn't build robots either. It supports six brands: FANUC, ABB, KUKA, Universal Robots, Yaskawa and Comau. The FANUC integration streams trajectory corrections through FANUC's Stream Motion interface, and GM was the first customer on it.

FANUC's education area at IMTS, a row of CRX cobots. The Inbolt integration on FANUC supports the CRX line. (My photo. Inbolt isn't in it.)

On opening day of IMTS, UR launched its Gen 7 platform, and Inbolt's vision now runs directly on the UR controller, sold by UR itself. In UR's release, Inbolt CEO Rudy Cohen put it simply: "available directly through UR."

So that's why I kept running into it. Inbolt builds one layer of software in the middle and uses other companies' hardware on both sides. It gets in the door through the robot makers' booths, controllers and sales teams. By the company's own numbers, it was in 20-plus factories in September 2024, 50-plus in June 2025, and is in 75-plus today, with more than 40 million robot cycles in 2025.

The upside of this path is real. No hardware R&D or inventory to carry. FANUC's and UR's salespeople open doors for you. The customer adds one camera and one software license and keeps the robot they already have. The downside sits in the same place: both ends belong to someone else.

Three days after the show

IMTS closed on September 19. On September 22, Cognex announced it would buy RealSense for about $500 million in cash. RealSense is the company behind the $314 camera in Inbolt's public demo.

There's a small irony here. At the show, UR's list of Gen 7 ecosystem demos had Cognex and Inbolt on the same line. Three days later, one of them announced it was buying the other's camera supplier.

The numbers below come from the release Cognex filed with the SEC. Intel started RealSense in 2014 and spun it out in 2025. RealSense expects $80 to $90 million in revenue this year, up more than 50% from last year, so Cognex is paying roughly 5.6 to 6.3 times revenue. On top of that, Cognex plans a three-year $56.5 million cash retention program for RealSense employees plus about $50 million in restricted stock. Together that's about a fifth of the purchase price. Cognex is clearly buying the team along with the product line.

Cognex CEO Matt Moschner described the goal as a "full-stack visual intelligence platform," running from industrial ID and 2D and 3D measurement all the way to 3D depth perception and robot navigation.

Anyone who has worked in inspection will notice a gap in the middle of that list. Cognex's cameras have always hung over the line, looking at a part and returning a verdict: pass or fail. RealSense cameras ride on a robot's wrist, look at a scene and return a position: where the part is and how to get there. When the first kind is wrong, you get a scrapped part or a missed defect. When the second kind is wrong, the robot moves to the wrong coordinates. Cognex's home ground is the first kind, and this $500 million is its ticket into the second. Cognex's own estimate of that market is about $600 million today and about $1.6 billion by 2030.

What to watch

For a middle-layer company like Inbolt, Cognex could play this three ways. It could be a channel, selling RealSense cameras into factories along with partners' software. RealSense CEO Nadav Orbach said what attracted him was Cognex's "global industrial customer base and go-to-market reach." It could build its own guidance software on top and compete head-on. Or it could buy a middle-layer company outright. The announcement doesn't say which way it leans.

I'm watching two things. First, whether the RealSense developer ecosystem stays as it is: the SDK, the partner program, and supply terms for third parties. Second, whether Cognex ships its own RealSense-based robot guidance software within a year of closing. If it does, the window for the middle-layer path starts to narrow.

If you're evaluating vision guidance for a line, ask one more question when you buy: how many 3D cameras does this software support, and how long does it take to switch? Before September 22, that was a theoretical question.

If you're building a startup, the borrow-both-ends path works. Inbolt going from 20 factories to 75 in two years proves it. But the moat can't be "we integrate with one camera." It has to be something neither end can take: the field data from tens of millions of cycles, and the few minutes it takes to go from a new part's CAD file to running on the line.

As for my deburring question, the answer is no. But chasing it showed me something. Inbolt can borrow its accuracy from the drawing and its sales channel from the robot makers. The camera end isn't up to Inbolt, and as of September 22 it's about to change hands. The deal is expected to close in the fourth quarter.

If you know an engineer who is picking a 3D camera for a line right now, send them this. The camera end is changing owners, and their comparison sheet may need one more column.

Subscribe now

On September 16, Siemens and Procter & Gamble announced that they are rolling out AI-based visual quality inspection across P&G's plants worldwide. The product is called Visual Inspection Cockpit. It runs on Siemens Industrial Edge, inspects thousands of products per minute, cuts scrap by 10 to 20 percent depending on the line, and commissions a new line five to ten times faster than a traditional vision system. Those are Siemens's own numbers, from its press center. I'm quoting them as given.

A hundred-year-old industrial giant, taking AI to global scale for the first time, chose inspection. Not welding. Not grinding. Not assembly.

Four weeks ago, in "Is Manufacturing at Dusk or Dawn?", I drew a map. This announcement landed exactly in the corner the map said it would.

1. The map, briefly

Two axes. Horizontal: cost of failure, from "redo it" to "crashed spindle, stopped line." Vertical: cost of verification, from "a glance" to "physical trial." Humanoid demos — cup from a cabinet, folded laundry — cluster in the bottom-left. Manufacturing — welding, deburring, precision assembly — lives in the top-right.

The order in which AI eats tasks is set by those two costs, not by how intelligent a task looks. Palletizing sat in the overlap between the two zones, so it commoditized first. Inspection sits in the cheapest-to-verify corner — when a model mislabels an image, nothing crashes — so it became industrial AI's first beachhead. The P&G rollout is that corner at scale.

That piece used the map as a diagnosis: if your pilot is stuck, find yourself on the map before blaming the model.

This piece uses it as a manual.

2. The claim: the axes are not fixed

Cost of failure and cost of verification sound like intrinsic properties of a process. Welding is just expensive to get wrong. Deburring is just hard to check.

They aren't. They are costs, and costs are engineered, not decreed by physics.

Where a task sits on the map depends on two things: what one failure costs you, and how long it takes you to find out. Both can be changed. Change one, and the task moves a step toward the bottom-left. Move it into the region where automation already works, and it gets automated — without waiting for a smarter robot.

The same map, with two arrows. Positions are qualitative — my judgment, no units. Deburring is dragged from the top-right to the middle: the first leg by making failure reversible, the second by making verification cheap. It lands near machine tending, a region that has been automated for years.

3. Dragging left: make failure reversible

Why is failure expensive? Because it's irreversible and the blast radius is large. A toolpath point that flies a meter off the part is a rerun on screen and a crash on the machine.

The ritual every robot programmer knows — teach, dry run, single-step, low speed, full speed — I wrote about in "The Builder Cannot Be the Verifier" as a stack of checks that don't depend on the brain that wrote the program. Look at it from a different angle today: it is a staircase, and a failure on each step is cheaper than a failure on the next. Crash in simulation: rerun. Drift off in a dry run: you saw it, nothing hit. Touch something in single-step: you touched a point, not a path. Scrape at low speed: you scraped paint, not a fixture.

That staircase is engineering on the horizontal axis. Each step you add drops the cost of failure one notch. Get it down to "redo it," and on this axis the task is roughly where folding laundry is — even though its tolerance is still ±0.3 mm.

In my own offline exploration of a die-cast deburring path, about a dozen real defects surfaced, all on screen: the part was lying upside down, burr directions pointed inward, two arms were handing the path back and forth. Cost: minutes. The same mistakes found on the line would cost a scrapped casting and half an hour of downtime. The error didn't change. What changed is where it was found.

4. Dragging down: make verification cheap

Why is verification expensive? Because you need a physical trial or a destructive sample to know whether it worked. Welds get ultrasonic testing. Assemblies get measured.

Inspection is cheap to verify for a very concrete reason: its output can be checked directly against labeled samples. One image, right or wrong, in a second, at no cost, replayable.

So lend that cheapness to other processes. There is exactly one way: hang an inspection step behind the process. Is it clean after grinding? "The Physics of a Burr" put it as "re-inspection, not prayer." The grinding step itself doesn't change, but its verification cost becomes the cost of one camera frame. Photograph each part after grinding, compare against labeled samples, send failures back, log the result.

There's a trap here. The inspection you hang on must be independent of the system doing the work. If the re-inspection uses the same model's judgment that generated the path, that isn't dragging — it's holding up a mirror. The builder's blind spots get copied verbatim into the builder's own checks. My collision check that passed three rounds and never once put the workpiece into the collision model — that was this trap.

5. Walking deburring through it

A taught deburring robot today: path from CAD, fixed force, verification by a veteran running a gloved hand over the finished part, failure meaning gouged base metal or ground air. Top-right corner.

First leg, left: generate the path offline, run collision checks in simulation, dry-run on the real cell with the spindle off, single-step it, then low speed. A crash goes from "incident" to "rerun."

Second leg, down: one image before grinding to locate this part's burrs, one after to confirm it's clean, both logged with the path. Verification goes from "the veteran's hand" to "the camera's comparison."

Where does it land? On the chart I put it near machine tending. Not the bottom-left — the tolerance is unchanged, the drifting burr distribution is unchanged, the physics hasn't moved. But that region has been automated for years.

The most interesting number in the P&G announcement isn't the scrap rate. It's "five to ten times faster to commission." Inspection was already in the cheapest corner, and they kept dragging it down inside that corner — squeezing the verification cost of every new line one more time. That is what scaling actually looks like: not finding the cheap corner, but engineering the cheapness onto every line.

6. Two questions for a stuck pilot

Whether the model is smart enough is the third question. The first two:

1. At this step, what does one failure cost? Can you add one stair so the next failure is one notch cheaper?

2. After grinding, welding, assembling — how long until you know it's right? Can you hang an independent inspection behind it so the answer becomes one image?

Every "yes" moves the task one step toward the corner where automation works. Same robot.

One falsifiable marker, for the record: if a ±0.3 mm process ever enters production on a stronger model alone — no simulation, no dry run, no in-line re-inspection engineered around it — this argument needs revising.

How to build this stack from zero — interface, state, reins — is what I'm doing, one installment at a time, on the other line.

If you know someone who is waiting for a smarter robot before they'll touch the deburring bench — send them this.

Subscribe now

I'm writing this to leave a timestamp I can be graded against. Every probability here is a subjective estimate. At the end I list the specific observations that would make me change my bet.

My bet on the endgame

Let me say up front that this is a question I find genuinely fascinating. But what I'm betting on isn't any single technical approach. It's the architecture that emerges once the division of labor stabilizes — plus a judgment about where the value ends up:

1. The endgame architecture has three layers. A centrally trained learned prior (a VLA plus a world model) covers the task distribution. Deferred computation at deployment — search, verification and constraint solving inside the learned model — corrects for distribution shift. A hard-constraint layer issues certificates. All three are necessary. The real design problem is the interfaces between them.

2. The prior becomes a commodity. Three to five vendors, cross-embodiment, priced per token. Value accrues in the deferred-computation layer: the world-model fine-tunes, verifiers, constraint definitions and failure data held by whoever owns the task.

3. Deployment order is set by who pays for failure. Settings that are constraint-dense, forgiving on reaction time and expensive to fail close the loop first — industry, logistics. Homes come last.

Subjective probabilities:

• Hybrid: learned prior + test-time search / verification — ~75%

• Pure end-to-end policy, no deferred computation — ~15%

• Explicit-model planning at the core, learning only for perception — <5%

• Something else — ~5%

One more: an explicit constraint / certificate layer becomes a standard component of industrial robots before 2030 — about 55%. Lower for consumer robots.

The rest of this piece explains why I'm betting this way, where the frontier actually is, and what would make me change the numbers.

A different axis: where the computation happens

The usual axis in the policy-versus-planning debate is whether the problem can be modeled as an MDP. The strongest result on that axis is an existence claim: when the objective depends on history, and there's no way to summarize that history in a fixed handful of numbers (no finite-dimensional sufficient statistic), no state-feedback law exists, and the policy has to be defined over histories. That's correct. But it tells you nothing about efficiency, and nothing about architecture.

A more useful axis: is the computation for a decision amortized into parameters, or deferred and solved at deployment time? Baking a plan into a controller is amortization; planning online is deferral. RL amortizes, MPC defers. A VLA amortizes; test-time search defers.

The payoff of this axis is that both sides' costs can be written down symmetrically:

Amortization's cost doesn't grow with state dimension — it grows with how many task and constraint distributions you have to cover. The query is O(1). Out-of-distribution failures are silent: the policy doesn't know it has left the distribution.

Deferral's cost grows polynomially with horizon and dimension, and exponentially with the branching of uncertainty. Its failures are explicit — infeasible, didn't converge — but that "explicit" is only trustworthy with a convex or complete solver.

Notice that each side has its own exponential: amortization is exponential in coverage, deferral in uncertainty. Any argument that counts only one axis reaches a one-sided conclusion. Count dimensions alone and planning wins outright; count real-time closed-loop behavior alone and policy does.

Why neither layer can be dropped

Write that symmetry as two necessity claims.

What you can't skip: solving online at deployment

Deferred computation is necessary. Any system with hard constraints needs a layer that solves online at deployment and can return a feasibility certificate. A policy's constraint-satisfaction rate is an in-distribution statistic, not a certificate.

More concretely: for constraints that only arrive at deployment — the obstacle set produced by perception, where the fixture happens to sit today, a window length the user specifies — a policy has to cover the entire constraint family in its training distribution, while a planner takes the constraint as an input and pays nothing to cover it. The exponential really shows up in how finely the constraint has to be described, not in the time horizon.^[1]

What you also can't skip: closed-loop reaction

Amortization is necessary. Any behavior that has to react in closed loop under uncertainty, faster than a solver can solve, must be amortized into a policy. Open-loop planning — receding horizon included — is structurally suboptimal under partial observability and randomness: it never probes the situation to see it more clearly before committing (control theory calls this dual control), and expanding every possible branch into a scenario tree puts you straight back on an exponential. The core value of a feedback policy is precisely that it amortizes closed-loop behavior into a function.

If both claims hold, the architecture isn't either/or. What's left is the interface: what the policy hands the planner (a warm start, a mode sequence, a terminal cost), and what the planner hands the actuators (a certificate, a refusal, or a corrected action).

Why the third layer stands on its own

Why pull hard constraints out as a separate third layer? Feasibility certificates exist only for convex (or convexifiable) formulations. Non-convex cases need a complete solver, and sampling-based planners are only probabilistically complete — sample long enough and they will "almost surely" find a solution, but when they don't, they can't tell you that none exists. So being correct-by-construction is a property of the formulation, not of "planning."^[2] The design rule follows: push hard constraints into a convex safety layer — control barrier functions, reachable sets, corridor constraints — between the policy and the actuators, and leave everything else to soft verification.

Four drivers and a template

Inference compute prices (high confidence). Still falling, and pushing the marginal cost of deferred computation toward zero. This is the underlying force behind every test-time-compute approach, and it isn't going to reverse.

But keep the two kinds of compute separate. What's getting cheaper is inference compute, and it feeds deferred computation. The big money going out the door right now buys training compute, and that feeds amortization. In September 2026, Figure signed with Nscale for up to 100,000 NVIDIA Vera Rubin GPUs on an initial $3.5 billion commitment, and the announcement says plainly that the compute is for training its next generation of models. The commitment is larger than all the funding Figure has publicly disclosed to date — roughly $1.9 to $2.3 billion — and the first of that compute doesn't come online until the second half of 2027. It's a clean statement of intent: the industry is answering the coverage problem with training compute.

If this essay's framework holds, that money can't buy what it's trying to buy. The exponential that binds on the amortization side is in coverage — not in compute, and not in state dimension. Compute can wring more out of the same data. It cannot conjure contact that was never recorded.

The non-homogeneity of robot data (medium confidence). Coverage across embodiments and scenes grows more than an order of magnitude more slowly than it does for language. A pure policy has to flatten the "constraint novelty vs. failure rate" curve with data, at enormous cost. But counter-evidence is appearing — zero-shot cross-embodiment transfer is starting to work — which weakens "there will never be enough data" while strengthening "the prior becomes a commodity": a prior that genuinely works across embodiments only needs a few vendors.

Contact physics (high confidence). Contact dynamics are non-smooth and their parameters aren't identifiable; you can't write the ODE down. That rules out explicit-model planning as the core: the model has to be learned. Planning doesn't disappear — it comes back as search inside a learned model, not as numerical optimization over hand-written equations of motion. The real opposition was never planning versus learning. It's learning a policy versus learning a model and planning in it. The same fact shapes the certificate layer for contact tasks: you can't get a pre-contact planning guarantee, so verification moves to post-contact inspection.

LLMs as the template (medium-high confidence). Pretraining → RL post-training → test-time compute plus verifiers: language models have walked that road, and robotics is replaying it two to three years behind. Robotics has one advantage over language here: physical outcomes are verifiable, so verifiers have ground truth. In text, the verifier itself is the bottleneck. In robotics it isn't.

The first three drivers imply a hybrid architecture. The fourth sets the timetable.

Where the frontier is

Deferred computation is already mainstream. Verifiability is almost untouched.

Deferred computation: already mainstream

τ₀-VLA (August 2026) is the most direct evidence. It's trained on 40,115 hours of real robot data. Across four long-horizon tasks, 10 trials each, the hierarchical version averages 45% success against 27.5% without the hierarchy. World-model-guided search at planning time lifts closed-loop success on a book-organizing task — one that includes initial arrangements never seen in training — from 60% to 90% (6 of 10 trials to 9 of 10); the other two tasks go from 50% to 70%. The largest gain lands on the task with out-of-distribution cases, which is the shape the theory of deferred computation predicts. But with 10 trials per task, a single trial is 10 points: this is consistent in direction, not confirmation. The absolute numbers also say this is still a research artifact, not a deployable stack.

π0.7 (April 2026) shows the progress on the prior side: multi-stage tasks in unseen environments; zero-shot cross-embodiment transfer — a robot that had never seen a laundry-folding task folds shirts with 80% success; and, out of the box, performance on tasks like operating an espresso machine that matches specialized RL-fine-tuned models. At runtime, subtask instructions come from a learned high-level language policy, or from a human coaching it; subgoal images come from a lightweight world model.

World models are already inside the main loop — but as conditional generators, not as verifiers. π0.7 also distills autonomous data from RL-post-trained agents, failures included, into the generalist model. That is the mechanism of prior commoditization: what specialist RL learns gets absorbed by the generalist, and the specialist no longer needs to exist on its own. The same team's multi-scale memory work pushes tasks to as long as fifteen minutes, handling path dependence with architecture rather than with state augmentation — an empirical confirmation of footnote 1.

Cosmos Policy turns amortize-versus-defer into a runtime switch: in direct policy mode it outputs only actions; in planning mode it uses predicted future states and values to rank candidate trajectories. That's one concrete implementation of "the interface is the core design problem."

Verifiability: almost nobody is working on it

The part of the frontier that isn't on this road — and what I think is the real gap:

• In every system above, "verification" means a learned value function doing soft ranking. There is no certificate. World-model error is unbounded; search lifts success from 60% to 90%, but it does not push the probability of violating a constraint down to a number anyone can state.

• Search happens at the subtask or semantic level. The low-level policy still executes action chunks open-loop, with no online layer enforcing continuous constraints.

• Model uncertainty quantification is missing. Without it there can be no certificate layer — a certificate is conditional on the model, and if model error has no bound, the certificate means nothing.

The gap isn't caused by technical difficulty. It's caused by incentives. Frontier labs optimize benchmark success on household tasks, where failure is cheap; the demand for certificates comes from industrial deployment, which isn't in their objective function. So this layer probably won't be filled in by frontier labs. It will be built one deployment task at a time.

I can say that with some confidence because one industry has already walked this road.

A precedent that already played out: defect inspection

What happened in two years

Around 2019, industrial defect inspection in China was still in the stage of educating customers. By around 2021 the paradigm had largely settled — and in the same window, the market turned into a price war. From customers starting to make serious demands to everyone doing it the same way took about two years.

In those two years, customers wanted two things: proof of certainty, and an explanation of how it worked. The supply side's answer was to explain the principles — convolutions, why this patch of pixels was called a defect. I gave that explanation many times, and the more I gave it, the clearer one thing became:

They couldn't follow it — and they shouldn't have had to.

You can't get a quality engineer to sign off on a line's verdicts by teaching them neural networks. What they wanted wasn't to understand the model. It was for something else to catch it when the model was wrong.

What finally settled wasn't a better explanation. It was a structure: the model makes the first call, hard rules backstop it, conventional metrology intercepts, and the parameters stay adjustable on site.

Hard rules are not metrology

One distinction matters here, or this precedent turns into "just add some rules": hard rules and conventional metrology are not the same thing. Hard rules are an engineering compromise — a pile of human-written if-statements, and the bigger the pile, the less anyone can say whether the model or the rules made the call. Metrology is something else. It produces a quantity with units and a stated uncertainty, backed by a calibration chain traceable to a reference standard. It doesn't explain the model. It goes around the model.

That is what a certificate is: its correctness doesn't depend on whether the model is right.

This maps onto the design rule above: feasibility certificates exist only in formulations you can actually model. Metrology is that formulation. Rules are not.

What this precedent can't be used for

I take three things from this history — but first, what it can't be used for. Inspection and contact work are not the same problem. Inspection decisions are low-dimensional and the takt time is fixed. More importantly, the measuring instruments already exist: calipers, vision measuring machines and profilometers are sitting right there, and wiring them into the process is an engineering problem. Contact tasks have no such ruler, so a certificate layer for them first has to answer "measure it with what?" Of the three points below, the first two are about what happened in this industry, and I'm confident in them. The third is extrapolation. Read it as a hypothesis.

First, the certificate layer was built after explanation failed. Customers wanted proof of certainty. The industry tried explaining the principles and got nowhere. What actually solved it wasn't getting people to understand the model — it was putting an independent measurement outside it.

Second, this layer was forced into existence by customers, not invented by researchers. No paper proposed this structure. It's the shape that got negotiated across the table from customers who refused to accept statistical guarantees. That's exactly why I don't expect frontier labs to build the certificate layer — not because they can't, but because nothing in their objective function pays for a missed defect.

Third, ownership of the constraints is migrating. Early on, field engineers tuned the parameters; over the last two years that has gradually passed to customers, who now tune them themselves. It looks like product maturity. What's really happening is that the right to define pass/fail is moving from the party that builds the model to the party that bears the cost of failure. If robotics reaches the same point — where whoever pays starts demanding proof — my guess is that the asset that accrues will be the same thing: not the model, but how the constraints are defined, and by whom. That's bet #2 above. Inspection gives it one case that has already happened. It is only one case.

The same goes for "two years." It was achieved with measuring instruments already in hand, and it doesn't transfer directly. All it supports is this: once the paying side genuinely starts demanding proof, this layer may not take long to build.

It also explains something from earlier: the inspection industry skipped the deferred-computation layer entirely and converged straight to "amortize plus certificate." The reason is prediction P2 below. Takt time in inspection is fixed, and the required reaction time is far shorter than any online solve — which puts inspection on the left side of the crossover, where online search can't deliver.

Falsifiable predictions

These four can be tested directly on systems that exist today:

P1 — Constraint-novelty curve. Hold in-distribution success fixed, and put on the x-axis how far the obstacle or fixture geometry sits from the nearest example in the training set (Hausdorff distance). A pure policy's failure rate rises monotonically with that distance; a hybrid's stays roughly flat, with a ceiling set by warm-start quality × solver completeness.

P2 — Latency crossover. Put "required reaction time / solve time" on the x-axis and there is a crossover: below 1, hybrid ≈ policy; above 1, hybrid ≫ policy. Where the crossover sits is measurable.

P3 — Silent failure rate. A pure policy's constraint violations go unflagged; the fraction of a hybrid's violations that get flagged ≈ solver completeness. That is the entire safety argument, and it can be counted directly.

P4 — Parameter extrapolation. On path-dependent tasks with a dynamically specified window length, a policy with sequence memory handles windows inside its training range and fails outside it; a planner holds for any parameter. Push the window parameter outside the training range and you have the test.

What would change my bet

• Search gains that shrink with data. If τ₀-style planning-time search gains go to zero after a tenfold increase in data, coverage can ultimately be solved by amortization, and the 15% on pure policy has to go up. This is the most important indicator; the ratio worth tracking is search gain over data scale.

• Zero-shot success above 95% without search. If the next generation of generalist models crosses that line with no test-time search, same conclusion.

• A market that tolerates accidents. If the certificate layer keeps failing to show up in industrial deployments, and failures simply get absorbed as an operating cost, then I've overestimated the demand for verifiability, and the 55% comes down.

All three can be tracked today. I'll be back in a year to grade this.

Where I concede

The prior still has to be learned, and the data hunger is real. A hybrid architecture reduces the coverage required; it doesn't eliminate it. I can't put a bound on by how much.

On contact and hybrid dynamics, planner completeness is weak, and the combinatorial explosion of mode sequences has no good solution. That part of the load still has to be carried mostly by learned mode proposals.

Certificates are conditional on the model. Model uncertainty quantification isn't optional — it's the premise the whole argument rests on. And it happens to be exactly what the frontier lacks most.

If you know someone about to sign off on a robot cell because it passed 99.7% of its trials — send them this before they sign.

Subscribe now

Notes

[1] This corrects claims of the form "representation complexity ~ d^N." d^N is the cardinality of the history space — the complexity of a lookup table, not the parameter count of a structured function class. A time delay is a shift register, a sliding window is a bounded buffer, a spectrum is a filter bank; RNNs and attention implement these exactly with very few parameters. The counterexample is language modeling: unbounded history, heavily path-dependent, solved by transformers with a polynomial number of parameters. What grows exponentially is the family of constraints you have to cover, not the length of the history.

[2] A local NLP solver reporting "infeasible" only means it didn't find a solution — not that none exists. Obstacle avoidance is exactly a non-convex feasibility problem, and contact is a hybrid, combinatorial one. "Return no solution if it's physically infeasible" comes with a discount in precisely these settings.

References

• τ₀-VLA: a Hierarchical Robot Foundation Model with World-Model-Guided Test-Time Computation, arXiv:2608.16885 (Aug 17, 2026) — https://arxiv.org/abs/2608.16885

• π₀.₇: a Steerable Generalist Robotic Foundation Model with Emergent Capabilities, Physical Intelligence, arXiv:2604.15483 (Apr 16, 2026; v2 Apr 24) — https://arxiv.org/abs/2604.15483

• MEM: Multi-Scale Embodied Memory for Vision Language Action Models, arXiv:2603.03596 (Mar 4, 2026) — https://arxiv.org/abs/2603.03596

• Cosmos Policy: Fine-Tuning Video Models for Visuomotor Control and Planning, NVIDIA, arXiv:2601.16163 — https://arxiv.org/abs/2601.16163

• World Model for Robot Learning: A Comprehensive Survey, arXiv:2605.00080 (Apr 30, 2026) — https://arxiv.org/abs/2605.00080

• Figure and Nscale Sign Strategic Partnership For Up to 100,000 GPUs on the NVIDIA Vera Rubin Platform, Figure (Sep 3, 2026) — https://www.figure.ai/news/figure-and-nscale-sign-strategic-partnership ; Nscale press release — https://www.nscale.com/press-releases/nscale-and-figure

• Figure Exceeds $1B in Series C Funding at $39B Post-Money Valuation, Figure (Sep 2025) — https://www.figure.ai/news/series-c

An American spent four years building an all-American grill brush, and found that finished parts from China cost less than his raw materials at home. He filmed half of the picture. This piece is about the other half.

The half he filmed

Destin Sandlin, of the YouTube channel Smarter Every Day, did something genuinely instructive: he and his partner John Youngblood spent four years trying to build a grill brush in which every part is made in America.

What came out was a serialized documentary about manufacturing. A decent big-box grill brush runs twenty to thirty dollars; his sells for $74.99, and after four years they still couldn't reach one hundred percent American sourcing. The details along the way cut deeper than the conclusion. When he asked a US injection-molding shop to cut a mold, the answer was blunt: "We don't make injection molds in America… we're not good at it. We have it done in China." The American molder sends its own molds to China. Destin refused to accept that, spent about a year learning to run a CNC mill, and cut the mold himself. The chainmail was darker comedy: they deliberately routed around China and picked an Indian supplier — and when the shipment arrived, it was made in China anyway. Set out to build a one-hundred-percent American brush; the chainmail leg of it looped back through China after all.

One episode title compresses the whole saga into a single question: "How Can We Get American Materials to Cost Less than Chinese Parts?"

That question set off an enormous discussion in English, nearly all of it aimed at the American half of the picture: hollowed-out supply chains, lost tooling skills, cost structures. All true. But walk through what has to happen for a block of steel to become a finished molded part: tooling, molding, trimming, inspection, packaging, a trip across the Pacific, tariffs. Every step eats money — and the finished part still lands cheaper than another country's bare material. "Cheap labor" doesn't explain that. Neither does "efficiency." Something on the far side of the Pacific has changed what pricing itself means.

This piece is about the half that never made it on camera: the physical reality on the Chinese side — and, just as important, why people on the two shores run two entirely different chains of reasoning on the same price.

The other half, in three numbers

Physical reality first. This part needs no ideology — just a few public numbers connected into one chain.

The first number: $1.19 trillion. China's goods trade surplus for 2025, customs data, the largest any country has ever recorded — $3.77 trillion out, $2.58 trillion in. Meaning: Chinese factories make more than China buys back by roughly the GDP of the Netherlands, and all of it has to find buyers abroad.

The second number: 73.0%. National industrial capacity utilization for the second quarter of 2026, per the National Bureau of Statistics — a six-year low, with manufacturing at 73.5%. Put crudely: of every four production lines, one sits idle. And this in a record export year — external buyers are already absorbing more than at any point in history, and capacity still isn't full.

The third number: 41 months. That is how long PPI — factory-gate prices — stayed below zero year over year: negative from October 2022, bottoming at −5.4% in June 2023, and not positive again until March 2026. Price is overcapacity's most honest thermometer. When a quarter of the lines sit idle, the marginal pricing logic on every order changes: if a quote covers variable cost and gets an idle line turning, it is worth quoting.

As for the 2026 turn — +3.5% in July — the statistics bureau credits imported input costs and improved supply–demand balance in some industries. Note what the combination implies: the same quarter prices turned positive, capacity utilization was still setting a six-year low. The price ruler moved; the clearing of quantity did not finish — one line in four is still dark. Keep that divergence in your pocket. The second half of this piece will need it.

String the three numbers together and you have the cause of "Chinese finished parts cheaper than American raw materials." Not subsidy, not corner-cutting, not a dumping conspiracy — at least not mainly. It is a flow problem: capacity has grown faster than domestic demand for years, and exports absorbed the difference. Once exports hit the tariff wall and the ceiling of global demand, the excess has exactly one place left to go — price.

To watch the chain run to its limit, look at solar. Module prices fell from about 2 yuan per watt in 2022 to under 0.7 by mid-2026, through the industry association's estimated minimum-cost line. The 21 listed solar companies that have issued first-half 2026 guidance forecast combined losses of ¥13.0–16.8 billion, with LONGi, Tongwei and TCL Zhonghuan alone accounting for more than ten billion. Now the counterintuitive fact: the losses did not push capacity out. Everyone is waiting for someone else to die first. That refusal to exit is exactly where the two analytical frameworks split hardest — which is what the second half is about.

Two chains of inference

Now change the question: why do the two shores read the same chain so differently?

Scroll the comments under Destin's videos, then scroll Chinese social media from the same months debating neijuan — "involution," the domestic word for grinding, self-defeating competition — and the official campaign against it. Both sides are discussing the same phenomenon; their vocabularies barely intersect. The answer traces back to schooling. An American engineer or buyer, even one who never studied economics, absorbed a default inference toolkit from basic education and business culture: opportunity cost, supply and demand, price signals, rational actors. A Chinese factory owner, even one who never read Das Kapital, got a different toolkit from middle-school politics class: productive forces and relations of production, accumulation and distribution, surplus and crisis. This is not a question of which toolkit is correct. They are two pairs of glasses: each sees what the other cannot, and each has a blind spot.

Feed one event — manufacturing overcapacity and the price war — through both chains:

The neoclassical chain runs: price falls below cost → rational firms cut losses and exit → supply contracts → price recovers → market clears. Hence: below-cost quotes cannot last, long-term contracts are risky, and government intervention — subsidies, industrial policy — only delays clearing and creates deadweight loss.

The political-economy chain runs: capital accumulation has self-expanding momentum → distribution tilts toward investment while labor's share stays low → domestic demand cannot absorb the output → the surplus exits through exports → when external absorption tops out, competition turns inward and vicious → profits and wages fall together, compressing demand further. In this chain the price war is not a road to equilibrium; it is a symptom of a structural contradiction that price signals alone cannot resolve.

The point is not which chain is more "scientific." It is that each makes testable predictions, and the predictions collide.

The neoclassical chain predicts that loss-making firms exit. In reality, nearly the entire solar main chain is in the red and capacity has barely moved — because the chain leaves out several variables: local governments welded to employment (a closed line is not just the shareholders' loss), the option value of holding a position in the chain (outlive everyone and the market is yours), and exit costs themselves (specialized equipment has almost no salvage value). Use the neoclassical frame to predict a Chinese supplier's behavior and you will systematically underestimate how long they can bleed. A side note: the analyst who has argued this chain hardest in English, Michael Pettis — persistent surpluses reflect suppressed household income, not comparative advantage — spent years as a minority view among Western peers. Chinese readers find him almost familiar. A heresy in one framework is a commonplace in the other. That asymmetry is this essay's thesis, walking around in the wild.

The political-economy chain predicts that without changing the distribution structure, overcapacity has no solution. Its blind spot is symmetric: it underestimates the final coercive power of the price signal. What arrived for Chinese solar in 2026 was not an infinite grind — it was the anti-involution campaign: mandatory efficiency standards led by the Ministry of Industry and Information Technology, in force from 2027, which amount to clearing the market with an administrative ruler where the price ruler failed. The grind has a boundary, and cash flow draws it. On that point the neoclassical frame has never once been wrong.

Remember the divergence from the first half? In March 2026, PPI printed positive after 41 straight negative months — while capacity utilization was still probing lows. Read that scene through each pair of glasses. Neoclassical: the price signal is finally back. Political economy: the price was hauled up by imported costs and administrative clearing, and the quantity contradiction has not moved. Which reading is right? Most likely each is half right — and that is exactly where someone wearing only one pair of glasses puts the position on wrong.

So, back to the quote sheet. It is neither "clearing is imminent" (the neoclassical optimism) nor "it can fall forever" (a straight-line extrapolation of surplus). It is a process with a clear mechanism and a clear boundary — and judging where your supplier sits inside that process takes both pairs of glasses at once.

How to read the quote

A checklist for each side of the table.

If you are an American buyer holding a too-good-to-be-true quote, don't reach for "subsidy" or "corner-cutting" first. Check three things:

1. Capacity utilization in that specific sub-industry, not the national average. 73% is a mean. Your category might run 85% — the quote is near true cost — or 60%, where the quote is marginal pricing: there is room to negotiate, and the supplier list will be reshuffled within two years.

2. Which way concentration is moving. In an industry deep into clearing (concentration rising), the low price is a survivor's scale efficiency — sign the long contract. In an industry where clearing hasn't started (everyone losing, no one leaving), the low price is a grinding posture — put a supplier-exit clause in the contract.

3. Their cash-flow signals. Payment terms are more honest than quotes: a supplier that starts stretching its own vendors and asking you for prepayment is near the edge of its grind, however low the number on the page.

If you are a Chinese supplier selling to American customers, the symmetric warning: price carries less weight in their decision function than you think. Compliance risk, continuity risk, switching cost — each carries a posted premium in their ledger. That is why the order didn't move after you cut 15%. In language closer to home: they are not buying the part, they are buying certainty across the whole supply relationship — and in their framework, certainty has a price.

Back to Destin's question — how can American raw materials come to cost less than Chinese finished parts? Once you have seen the other half of the picture, the question turns out to have a time axis. Today's 0.7-yuan solar module and below-raw-material molded part are snapshots from the middle of a clearing process, not a steady state. Through the neoclassical chain, those prices eventually return to cost. Through the political-economy chain, the road back will be far longer and far more painful than the textbook predicts. Both chains are half right — and no one making cross-border supply decisions can afford to believe only half. The most expensive mistake in this business has never been miscalculating a cost. It is using your own chain of inference to predict a counterparty who thinks in the other one. Learn to read both ledgers. That skill only gets more valuable from here.

If you buy from — or sell to — the other side of the Pacific, forward this to the person across the table. It reads differently from each chair, which is the point.

First Principles Manufacturing — Dispatches from a Novi robotics lab.

Subscribe now

Manufacturing is not hard because it is backward. The way it looks today — the hierarchy, the crews, the shift handovers, the old hands — is a solution, optimized over decades. The real question is what happens when the constraints that solution was built for start to move.

1. One wall apart

Earlier this month, Hardware FYI ran a good piece called Why is Manufacturing Difficult? The list is accurate: cycles are long — qualification, ramp, and production all run in parallel; complexity is high — a design has to become a repeatable process; decisions cast long shadows — cut the tool once and the mistake follows you for three years. Nothing on that list is wrong. But a list describes the difficulty. It doesn't explain it.

To compress the list into one question, walk into any car plant and stand at the wall between the body shop and final assembly.

On one side of the wall: Mercedes' Alabama plant runs more than 1,650 robots, and about 1,250 of them are in the body shop — sparks everywhere, hardly a person in sight. On the other side: final assembly is full of people. ABB's managing director for automotive OEMs put a number on it in 2020: less than 5% of final trim and assembly is robotic — worldwide. The production chief of Volkswagen's Trinity plant said it plainer still: "Assembly is still 90 percent manual work."

Same company. Same capital. Same engineers. Same purchasing department. One wall apart, the automation rate drops by an order of magnitude.

Is it for lack of trying? Tesla tried. After the Model 3 ramp, Musk wrote it himself: "Yes, excessive automation at Tesla was a mistake. To be precise, my mistake. Humans are underrated."

So the question is not "why is manufacturing difficult." It is: what decides whether a task lands on the machines' side of the wall, or on the humans' side?

2. Automation is not a function of technology

Widen the frame from one car plant to all of manufacturing and the answer surfaces on its own.

A qualitative map — no units, positions are author's judgment, anchors cite public data. The frame follows Hayes & Wheelwright's product–process matrix (HBR, 1979).

In a semiconductor fab, wafers ride overhead rails in sealed FOUP pods and no human hand touches them. In apparel, nearly two hundred years after the sewing machine, robots still have a "limited presence". Inside a single phone: an SMT machine places 20,000 to 150,000 components per hour, while the final-assembly halls next door hire two hundred thousand people for peak season. Inside a single food plant: a canning line runs two thousand cans a minute with almost nobody watching, while poultry deboning remains "primarily manual". Aerospace is the summit of advanced manufacturing, and Boeing's 777 fuselages are still fastened by machinists.

Put these on one chart — product variety times the share of compliant, floppy parts on the x-axis, degree of automation on the y — and every industry falls near the same downward line. What sets the automation rate is not how advanced or how rich an industry is. It is two parameters of the task itself: is the geometry certain, and is this piece the same as the last one.

The companies that charged the line head-on left records:

• Apple ran a secret lab in Sunnyvale from 2012 to 2018 to automate iPhone and MacBook assembly. Robots couldn't drive tiny screws — they can't feel torque. The automated insertion of the 88 keyboard screws on the 12-inch MacBook kept failing and delayed the product by six months. The lab closed in 2018.

• Boeing's FAUB program put KUKA robots on 777 fuselage riveting — roughly 60,000 fasteners per aircraft. Rework piled up from 2015 on, and in 2019 Boeing pulled the robots, keeping automated drilling and handing the fastening back to machinists. Note the detail: automation didn't leave. It retreated to the sub-task with certain geometry.

• SoftWear's sewing robots were announced in 2017 to make 800,000 Adidas T-shirts a day in Arkansas, with 400 jobs promised. A few years later the plant's registered headcount was nine.

• Foxconn promised one million robots in three years in 2011. By late 2012 it had installed about 30,000 — and hired roughly 100,000 more workers in the same period.

The most extreme point on the chart is the wire harness. A car carries more than 3,000 individual wires, around 4 kilometers of them, roughly 60 kilograms — and the number keeps growing: by Volvo's own like-for-like count, wire length per car went from 1,000 meters in 2000 to 2,800 meters in 2020. As for installing it, engineers from Chalmers, Volvo and Scania put it bluntly in a 2024 review: the job "has been performed entirely manually by skilled human operators," and to date "no practical automated solutions have yet to be witnessed in actual production." For the machinist's version of why: harness installation is five steps — soften, transport, untangle, route, connect. Machines can do the first two. Each of the last three means handling an object that deforms under its own weight and differs batch to batch.

This line has barely moved in sixty years. Industrial robots entered the factory in 1961; today the car industry's robot density is nine to ten times the manufacturing average — and every one of those robots is piled into the upper-left corner of the chart.

It holds within a single country too: Poland runs 247 robots per 10,000 employees in automotive and 62 everywhere else. Robots did not flow to where labor is scarcest. They flowed to where geometry is most certain.

3. The org chart is a solution

Now look at the lower-right corner — the corner machines couldn't enter and hands kept. What does the organization look like down there?

Deep hierarchy, orders passed level by level. Crews of a few people, an old hand training the new one. Three shifts, with a meeting at every handover. A traveler document that follows the workpiece, signed at every step. When something goes wrong: escalate, investigate, assign a name.

Plenty of people read this as backwardness — legacy structure waiting to be cleaned up by digitization. Put on a different pair of glasses: this is a structure that has been optimized, repeatedly, under a specific set of constraints. Every feature answers a specific cost:

• Hierarchy, level-by-level reporting — Moving information is expensive: remote readers can't see floor state

• Crews + apprenticeship — Knowledge won't encode: feel and experience don't fit in documents

• Shift-handover meetings — State won't transfer: the machine's and the workpiece's state live in someone's head

• Paper travelers, signatures — Verification is expensive: traceability runs on physical evidence and named people

• Approval chains — Errors are costly: one bad decision physically scraps things

None of this is my invention. Coase settled it in 1937: firms exist because using the price mechanism itself has a cost — "the main reason why it is profitable to establish a firm would seem to be that there is a cost of using the price mechanism." Chandler gave manufacturing its version in The Visible Hand: modern business enterprise first appeared when the volume of activity made administrative coordination more efficient than market coordination — the management hierarchy is not bureaucratic inertia; it is itself a technology, the best engineering answer of the railroad-and-telegraph era to the coordination problem. And Conway's law, usually quoted forward — systems copy the structure of the organizations that design them — should be read backward on a shop floor: an organization's shape is a copy of its communication structure.

Look back at the Hardware FYI list through these glasses — long cycles, high complexity, hard coordination — and the three items collapse into one: coordination is expensive. And the army-style organization is the best machine humans have ever built for operating under expensive coordination.

Calling it an army is not a figure of speech.

4. Armies change shape when communication does

The army is the most-studied high-coordination-cost organization in history, and its history of shapes is a history of communication technology.

Prussia's Moltke inherited a problem: railroads and the telegraph had made war too large for any single commander's head — van Creveld gives it a full chapter in Command in War, titled "Railroads, Rifles, and Wires." Moltke's answer was not to grip harder. It was two things: the general staff — a corps of uniformly trained officers, in effect one operating system installed across the whole army — and the doctrine later called Auftragstaktik, mission command: the commander states the intent; how to execute is left to the officer on the spot.

A hundred and thirty years later, bandwidth jumped a few more orders of magnitude and the army changed shape again. Afghanistan, 2001: twelve-man special-operations teams on horseback used satellite radios and laser designators to call B-52 strikes in real time — the official U.S. Army history records these detachments wielding the striking power that used to take an entire corps-level chain of command. McChrystal later compressed that whole organizational lesson into one line: it takes a network to defeat a network.

The rule is clean: every time the cost of communication and verification steps down, the organization gets one level flatter, its units one size smaller, its authority one notch lower. The army got its telegraph, and then its satellites. Manufacturing's hierarchy and crews still hold the shape of the previous era — not out of stubbornness. Its telegraph never arrived.

5. Plug in the new variable

Now plug in the AI agent. First, clear away a distractor: the robot was never the variable. Sixty years of robotics did not change the shape of the manufacturing organization — it took over the muscle work in the upper-left corner and swapped operators for maintenance engineers. The hierarchy stayed. The handover meeting stayed. Muscle was never what set the organization's shape. Coordination was.

Agents hit exactly that layer: reading state, carrying intent, running verification — the cost in every row of the table above. Link by link:

Design → process. Today: throw drawings over the wall, hold reviews. The locked constraint: design intent can't reach the floor. With agents: process constraints computed back at design time.

Production planning. Today: planners + Excel + morning meetings. The locked constraint: line state can't be read out. With agents: state readable live; replanning in minutes.

Purchasing / supply chain. Today: emails and chase-up calls. The locked constraint: supplier state invisible. With agents: cross-plant state reads (crosses firm boundaries — slowest).

Shop-floor execution. Today: crew chief assigns, briefs verbally. The locked constraint: intent travels through people. With agents: mission command: state the intent, guidance at the station.

Shift handover. Today: a meeting + handwritten notes. The locked constraint: state lives in heads. With agents: state transfers, and replays.

Quality. Today: dedicated inspectors + stacked reports. The locked constraint: verification expensive, delayed. With agents: verification embedded at the station, closed loop.

Maintenance. Today: the old hand's memory + escalation. The locked constraint: knowledge won't encode. With agents: fault history queryable, diagnoses accumulate.

This is the organizational meaning of the agent loop I wrote about in Is Manufacturing at Dusk or Dawn? That piece was about the machine layer: interfaces that can't enter the loop get squeezed out. This piece is the same judgment one level up: once the interfaces are in the loop, the organization wrapped around them changes shape.

Look at the two arrows on the chart. Agents don't push against the sixty-year-old line — they enter the coordination layer on both sides of it. Upper left: take over the scheduling, parameters and yield loops of machines already automated. Lower right: don't replace the hands — give them eyes and memory. Work instructions, live verification, variant data delivered to the station. The curve doesn't move. The organization around the curve does.

6. The shape of the endgame

Follow the constraints and the endgame is not the lights-out factory. Lights-out assumes the bottleneck is muscle — but where muscle could be automated, automation started sixty years ago, and where it couldn't, four companies just re-verified the fact with real money (the list is in section 2).

The endgame looks more like the army after Moltke:

• Flatter. Hierarchy exists because moving information is expensive; once state is readable, the relay function of middle layers hollows out.

• Smaller units. Crew size is set by coordination overhead; with handover and traceability carried by agents, two or three people run a section of line — the shape drifts toward the special-operations team.

• Authority sinks; command becomes mission command. Humans state intent and accept the result; the carrying, checking and recording travel in the loop. This is the organizational version of the wall I drew in The Builder Cannot Be the Verifier: the human stands on the verification side.

• Humans don't exit. The lower-right half of the chart will belong to human hands for a long time. What changes is how large an organization stands behind each pair of hands. An Iron Man suit, not an empty factory: one technician wearing an agent calls on the whole chain's capability — the way twelve men on horseback called on a B-52.

Three falsifiable markers, on the record:

1. If, five years after mainstream industrial agent products reach general availability, the plants that adopted them show no statistically visible change in management depth or crew size — the law "organizational shape is a solution to coordination constraints" is wrong.

2. If products that replace muscle head-on (humanoids swapping whole lines of people) reach meaningful revenue at scale before coordination-layer products do — this piece's test for where to enter is wrong.

3. If wire-harness installation gets fully automated in volume production — the sixty-year line in section 2 has moved, and this whole piece needs rewriting.

7. One question

If you are evaluating a manufacturing AI product — one you might build, or one you might buy — ask one question:

Does it attack the muscle constraint, or the coordination constraint?

Attack muscle, and you are fighting sixty years of robotics for the hardest bone on the chart, standing in line behind Apple, Boeing, SoftWear and Foxconn. Attack coordination, and your competition is Excel, whiteboards and the shift-handover meeting — sixty years without a serious challenger, with the whole shape of the organization pressing on exactly those costs, waiting to move.

How to build a system that enters the loop and takes over the coordination layer — I'm building one, episode by episode, on another line. This piece is why the entry point is there. That line is how.

If you know someone who still runs three shift-handover meetings a day — send them this. They’re living in the chart above.

First Principles Manufacturing — Dispatches from a Novi robotics lab.

Subscribe now

Two days ago I wrote that any step that can't be called by a program gets squeezed out. Today Anthropic turned "can be called" into a standard.

On August 27, Anthropic released the research preview of MHS — the Model Hardware Standard: a shared specification for AI agents to safely operate physical devices. If MCP is how agents reach data, MHS is its hardware sibling. A standardized driver on the device side abstracts an instrument into primitives like read and write ("get temperature," "set temperature"), with natural-language self-description so agents can discover devices on their own. It's callable over MCP, the command line, or an API; model-agnostic, not tied to Claude; open-sourcing is announced.

Two numbers from the first cohort, picking the hardest ones. Carnegie Mellon went from bare equipment to a completed dilution curve in eight hours — the vendor-integration route runs in weeks. On QuEra's quantum computer, recovering a titanium-sapphire laser's lost lock used to take a human 150 seconds with a 58% success rate; now it takes 6 seconds, succeeds 99.3% of the time, and no one touches anything.

Why I'm watching: for the past year in Novi I've been building the dialect version of this — one command model for industrial machines, exposed as both CLI and HTTP/gRPC, so any agent can drive the system without a GUI. When I saw MHS list MCP, the command line, and APIs as its three control mechanisms, I'll admit I laughed. Convergent evolution.

And because I've built this wheel, I don't want to write the "a giant has entered, the future is here" piece. Last Tuesday, in Is Manufacturing at Dusk or Dawn?, I gave three tests for whether a step can enter the agent loop: can it be called by another program, can it hand over state mid-task, does it get a check that isn't its own. Conveniently, I can now grade the new standard on my own exam.

Question one — can it be called: answered. That is MHS's definition. And there is one line in the official limitations worth reading twice: MHS "doesn't yet work with hardware that lacks a programming interface." That is exactly the line I meant by "dawn lights only half the floor" — now written into the standard's scope. The machine on your floor with a touchscreen and no API just moved one step further from the loop.

Question two — state handover: half credit. The rudiments exist. Janelia's microscope rig keeps its entire state in a standardized dictionary in shared memory, and in Genentech's error-recovery case the agent carried the context — "this error code comes from physical bubbles" — through the rest of the run. But that is device state, not task state. When one agent has done half the job and another takes over, where is the standard slot for the handoff? Nothing in the preview materials yet. Most production work doesn't finish in one breath; until this is answered, manufacturing can use MHS only for short, single-shot tasks.

Question three — an independent check: half credit. The right pieces are there: safety limits enforced at the device level, not the agent level — the laser-power cap belongs to the device, and the agent can't exceed it even if it wants to; in testing, six injected faults (missing plate, rotated plate…) were all blocked before any device moved; risky actions stop and wait for a human. All correct. But look at the other scene in the closed-loop experiments: the party that judged "this fit is too poor — discard the plate and rerun" was the agent itself. The builder is still its own verifier. In a lab, that's efficiency. On a production line, that's an audit problem. A lab can owe this answer. A factory can't.

Plug it into a robot arm, and here is what happens. One disclosure first: the standard's text is not available — the research preview runs on a waitlist (modelhardwarestandard.com), there is no public schema, and open-sourcing has no date. So what follows is the primitives the announcement disclosed, plus a year of my own time spent driving arms.

A moving arm has three loops inside it. The servo loop: kilohertz, torque and position, living in the drives. The motion-control loop: 125–500 Hz, trajectory interpolation, living in the vendor controller — UR's RTDE interface runs at 500 Hz. The task layer: single-digit hertz and below, program steps and waypoints. MHS's read/write primitives live in the task layer: write a target pose, set a speed, read the joint states. The two real-time loops below, MHS doesn't touch — and can't. An agent sitting behind MCP is hundreds of milliseconds per round trip at best, two to three orders of magnitude too slow.

From that, day one falls straight out. What works: machine tending, palletizing, positioning for inspection, multi-device orchestration — Doosan's preview tests are exactly "automated quality assurance plus multi-robot coordination" — and the most interesting class of all: the agent rewrites parameters while the device closes its own loop. QuEra's 99.3% is that template. The PID loop runs locally; the agent only tunes it. What doesn't: grinding, deburring, welding — contact tasks. Force response has to close at millisecond timescales, and the agent is three orders of magnitude behind. On day one under MHS, an arm is still a position-controlled arm.

But contact tasks contain one slow loop, and it happens to be the agent's home turf: drift. Burr distributions drift batch to batch as dies wear; the veteran compensates by hand every day, and nobody records the compensation — it evaporates at the end of the shift. I wrote about this in the burr piece. Leave the fast loop to local force control; the slow loop — read last batch's corrections, write next batch's parameters — is exactly what read/write primitives can standardize. If MHS wants a future on factory floors, this is the direction it should grow.

And one seam the announcement leaves open. Safety limits are device-level: speed, force, workspace caps the agent can't exceed even if it wants to. Right design. But crashing into a fixture takes only a semantically legal write — a target pose inside every limit. A device-level cap doesn't know where your tooling sits; a production line's interlocks have always been cell-level. The layer between the device driver and the cell's safety model is, for now, empty in the standard.

One list that's easy to skim past: among the first hardware vendors building MHS support are Universal Robots and Doosan. The cobot makers have moved. That is not a lab-curiosity signal.

The practical part. If you buy equipment: add one line to your checklist — does it have a programmable interface, and does the vendor have an MHS roadmap. Over the next five years that line will outweigh most of the specs on the datasheet. If you build industrial AI: the interface layer is being standardized and will be open-sourced. The window for "I can connect to the machine" as a business is closing, and the value is moving to the two ends — agent-readiness on the device side, and the independent-verification layer above it, which still has no standard answer. That second end is still empty.

Forward this to the engineer you know who is still writing their Nth proprietary driver for one machine — the next one might follow a standard instead.

First Principles Manufacturing — Dispatches from a Novi robotics lab.

Subscribe now

People will tell you manufacturing had its decades of development — mature, saturated, done. Maybe. But there has never been a moment when this much intellectual firepower was pointed at this industry.

1. Two storylines

Physical AI is entering the factory through two storylines, and they run on separate channels.

The first: the end-to-end, closed-loop robot — an AI and a body fused into one device. The humanoid is its poster child. Camera in, joint angles out, and no human ever wrote a line of process logic in between. March’s GTC was this storyline’s home game: Jensen Huang said every industrial company will become a robotics company, with 110 “robot brain” developers in the audience. GR00T N1.7 went to commercial licensing under Apache 2.0; N2 got a preview.

The second: existing machines, wrapped in an agent loop and layer after layer of guardrails — a system that accumulates. This storyline doesn’t build new bodies. It takes the bodies we already have — PLCs, robot arms, engineering toolchains — gives them interfaces an agent can call, stacks independent checks outside those interfaces, and lets every call and every check leave a trace that compounds. Hannover Messe in April and the ninety days after it were this storyline’s home game. Siemens shipped Eigen, an agent that writes PLC code inside TIA Portal and validates its own work — in Siemens’ own words, it “plans, executes, and validates” engineering tasks end to end. It shipped as generally available, in front of 600,000 TIA Portal users; Siemens says more than 100 companies in 19 countries are already using it. Rockwell strung Emulate3D, FactoryTalk Design Studio and a Copilot into one pipeline — the controller project is fully tested in simulation before it ever touches hardware — and took it commercial in May. On June 23, Beckhoff released TwinCAT CoAgent, which at its core is an MCP client: any model plugs in, local models included, air-gapped if you need it.

The two storylines are in very different places. The first is still looking for a cell — a workstation forgiving enough, slow enough, reversible enough for a humanoid to prove itself in. The second is rewiring manufacturing at scale — not in one cell but across the engineering toolchain, with three hundred-year-old giants moving in a single quarter.

This piece is about the second storyline. Not because the first doesn’t matter — because the second is actually happening, while most people are watching the first.

2. Why the first storyline is still looking for a cell

I’ve written about the wall this path runs into (The Submillimeter Trap of Embodied AI): an industrial robot’s repeatability and its absolute accuracy differ by a factor of twenty, every precision process in production today is built on repeatability, and the end-to-end paradigm thinks in absolute positioning. That wall is still standing. The models that shipped this year did not knock it down.

Same machine, same datasheet: repeatability 0.025 mm, path accuracy 0.53 mm — a 20× gap, with the ±0.3 mm deburring tolerance sitting right between them. Data: ABB IRB 1200 official datasheet.

So “still looking for a cell” is not a sneer. It’s a statement of physics: the cells a humanoid can occupy today live where precision is loose, tolerance is high, and failure is reversible — and that is not where most of manufacturing lives.

A qualitative map — no units, author’s judgment. Humanoid demos sample the lower left; manufacturing lives in the upper right. The two annotated points tell one rule: the order in which tasks get eaten is set by verification cost and failure cost, not by how “intelligent” the task looks. Palletizing sits in the overlap — it commoditized first. Inspection sits in the cheapest-to-verify corner — it became industrial AI’s first beachhead.

But this piece isn’t a retraction of that one. Quite the opposite. That piece said the “model holds the grinder itself” road is hard. This piece says a different road is quietly becoming fact: the model doesn’t need to hold the grinder. It needs to be able to call the machine that already knows how.

And that changes the test. The question is no longer “how smart is this machine.” It’s “can this machine be called.”

3. Three tests, and a blunt claim

First, what “inside the agent loop” means. An agent’s core move is simple: read the current state, pick a tool, the tool runs, the result comes back into context, look again. I wrote in “The Builder Cannot Be the Verifier” that this loop takes a few dozen lines of code. The hard part is the ring around it — who may call what, what gets checked before a call, who confirms the result, how you replay what it saw when something goes wrong.

For an industrial process step to enter that loop, three things are the floor:

1. It can be called, structurally. Not “there’s a screen you can click” — another program can send it instructions in a defined format and get results back in one.

2. Its state can be read out and injected back. The agent has to know which operation the line is on, where the workpiece sits, how far the last pass got — and a human has to be able to take over mid-task.

3. Its actions can be verified independently and replayed. Every execution gets a check that does not belong to the executor, and afterwards you can see exactly what it saw.

These read like software engineering. They’re what the shop floor has been doing for thirty years. Teach, dry-run, single-step, low-speed, full-speed — the whole ritual of commissioning a robot boils down to one sentence: the mind that wrote the program can’t be trusted, so wrap it in layers of checks that don’t depend on it. The shop floor had harnesses long before software gave them a name.

The word accumulates lives in test three. Every pit you fall into — a coordinate frame off by one fixed transform, a geometry that breaks the standard simplification — becomes a check once you’ve hit it, and the next part never pays that tuition again. The compound interest isn’t in features. It’s in constraints that don’t pay tuition twice. That is why the second storyline can scale: it accumulates. The first storyline relearns half of everything each time it changes cells.

Now the blunt claim: any step that can’t meet those three tests will get squeezed out, fast.

The mechanism isn’t technological backwardness. It’s cost structure. Picture a chain where eight of nine steps can now be run by agents — proposal, simulation, deployment, tuning, monitoring, anomaly triage, reporting, review — and one step still needs a human hand. Its absolute cost hasn’t moved. But it just became the only place the whole chain waits, and its relative cost explodes. Capital routes around bottlenecks. It doesn’t wait for them.

Notice what this has nothing to do with: how smart the machine is. An ordinary six-axis arm that an agent can call will outlive a “smart” device that nothing can call.

4. What an AI-native PLC looks like

Take the claim to the most concrete object on the floor: the PLC.

The precondition is already met: the PLC is turning into software. Siemens’ S7-1500V virtual PLC runs on industrial PCs and servers; its fail-safe variant has TÜV certification to IEC 61508 and is running at pilot customers. At Hannover this year, Siemens’ three entry points for manufacturers were the virtual PLC, Industrial Edge for AI workloads, and an open engineering toolchain. Only after control logic moves from dedicated silicon onto standard compute does “callable” become technically possible — you can’t give a structured interface to a board that only speaks ladder logic.

But an AI-native PLC is not a chat window bolted next to a PLC. I wrote about this distinction two years ago: stuffing an AI feature into an existing UI is AI-powered; an architecture that an outside agent can actually operate is something else. Back then I called it AI-ready — leaving a door open for the AI that might come. I wouldn’t put it that way anymore. The door doesn’t need to be left open. The AI is already standing inside it, and the question has become: what happens to the things that have no door.

An AI-native PLC, translated through the three tests:

• Its programs are generated by an agent and validated by a loop that doesn’t belong to that agent. Eigen’s validate, Rockwell’s fully-tested-before-hardware — both are this layer.

• Its runtime state is readable and injectable by an agent — structurally, not by exporting a spreadsheet.

• Every change is replayable and auditable.

Scan cycles, determinism, safety circuits — none of that goes away. It migrates from being properties of the PLC to being the constraint layer around the PLC: checks bolted on outside, stackable, no need to touch the tool itself. An AI-native PLC is not a smarter PLC. It is a PLC surrounded by discipline.

Robot arms, one paragraph, same logic. The change that matters this cycle is not whether the arm can learn — push that line far enough and you hit the wall in section 2 again — but that arm controllers are starting to expose interfaces to agents. Strip the Physical AI packaging off what the arm makers on that GTC list are building on NVIDIA’s platform, and the most substantial layer underneath is exactly this.

5. Three giants, three bets

Half a year of public moves is enough to make out three postures. I’m not ranking them — I don’t know who wins, and you know I don’t — just naming what each is betting on.

Siemens is betting on the closed loop. Eigen lives inside TIA Portal, the virtual PLC runs on Industrial Edge, the toolchain is theirs end to end. Generation, validation, deployment — one house. The upside is the most complete experience on offer. The cost: if this agent can only be used inside TIA Portal, and outside agents can’t call it, then it’s the very thing section 4 warned about — a door that opens inward. I can’t tell yet which way it opens. That’s in the falsifiable markers below.

Beckhoff is betting on the body. CoAgent isn’t a brain — it’s an MCP client. Any model plugs in; local and air-gapped work too. The bet: brains get swapped and brains depreciate, but the body that is easiest to call does not. Of the three, this posture maps most cleanly onto the three tests.

Rockwell is betting on borrowed brains. Azure, Microsoft Foundry, Azure OpenAI — wired into its own Emulate3D and Design Studio for closed-loop validation. It doesn’t build the brain and doesn’t preach openness; it plugs someone else’s brain into its own verification loop. Fast off the line. The brain lives in someone else’s house.

Behind the three bets, one shared judgment: whoever makes “being called” cleanest becomes the default body of the agent era; whoever locks the agent inside its own UI repeats the oldest mistake in this business — hanging an AI sign where the AI can’t reach.

How fast is “fast”? I won’t name a year. My yardstick: watch how long these products take to go from developer preview to GA. Announced in April, commercial in May, released in June. That is not the ten-years-a-generation cadence this industry is used to.

6. Falsifiable markers

A prediction that can’t be falsified is a mood. Four markers; I’ll come back and grade myself:

• If into 2027, a giant’s agent still works only inside its own IDE, uncallable by outside agents → revise section 5’s read on that giant’s bet.

• If a mainstream VLA enters a precision process station with Cpk data (±0.3 mm deburring, grinding) → revise sections 1–2, and “The Submillimeter Trap” alongside.

• If virtual PLCs fail to reach mainstream production lines within three years → revise section 4 — “precondition already met” was premature.

• If two years from now, agent calls still stop at the engineering toolchain — writing programs, running simulations — and haven’t entered production runtime: online tuning, anomaly handling, handover → revise section 3 — “rewiring at scale” only rewired the engineer’s desk, not the factory.

7. Dusk or dawn

Back to the opening line.

The people who say manufacturing finished developing decades ago are right about one thing: most of what could be automated was automated, everything lean has been leaned, and the margins are paper. By that story, this is a mature industry, and a mature industry’s next stop is dusk.

Then look at where the intellect is flowing. Crunchbase’s numbers: in the first half of 2026, global venture investment in physical AI was $47.4 billion across 521 deals — more than the $41.9 billion of 2022 through 2024 combined. On PitchBook’s definition, 2025 alone was $27.6 billion across 1,009 deals. A hundred and ten robot-brain developers at GTC. Three century-old industrial giants shipping agent products inside one quarter. That money and those people are not aiming at a sunset industry.

Six months now outweigh three years. Definition: Crunchbase’s physical AI category — robotics, AVs, aerospace, drones, industrial automation, sensors.

We’ve seen this movie recently. After the ChatGPT moment, a flood of research poured into language models and took them from “can chat” to “can work” in about two years — not because of any single breakthrough, but because enough smart people stared at the same problem at the same time. The same thing is starting to happen to manufacturing.

The price of constant-quality intelligence fell ÷1000 in three years (a16z, “LLMflation”; the GPT-4-class tier is ÷62 since March 2023). Cheap brains flow toward cheap verification first — which is exactly why the rewiring started in the engineering toolchain, not on the production line.

So my answer is dawn. With two reservations — and the reservations matter more than the answer.

First, this sunrise will be slower than the LLM one. LLMs matured in two years because their verification loop is cheap: text, benchmarks, minutes per round. Manufacturing’s verification loop is physical. A toolpath point that flies a meter off course is a re-run in simulation and a crash on a production line. The tolerance for error that exists offline does not exist on the floor. No amount of intellectual firepower goes around that loop’s speed — so the intellect pours first into wherever verification is cheap: engineering tools, simulation, offline generation. Which is precisely where the second storyline is happening right now.

Second, dawn only lights half the floor. The lit half is whatever can enter the loop — callable, state readable, verifiable, replayable. The other half — the steps only a human hand can touch, no interface, no independent check — for them, this is dusk. Not because they broke. Because they are about to become the only place the whole line waits.

Dusk or dawn doesn’t depend on which industry you’re in. It depends on whether you’re inside the loop or outside it.

8. A judgment call for decision-makers

You don’t need to know what MCP is. Take three questions to every machine and every piece of software you’re about to buy:

1. Can another program call it in a defined format — not “it has an API,” but every key operation?

2. Can its current state be read out, and can a human take over mid-task?

3. Does every action it takes get a check that isn’t its own — and can you replay it afterwards?

One “no” out of three, and its depreciation curve needs to be recalculated. Not because it’s a bad machine. Because it’s about to become the place where everything else waits.

How to build a system that can enter the loop — the interface, the state, the reins, from zero — is what I’m doing episode by episode on another track. This piece is the why. That one is the how.

First Principles Manufacturing — dispatches from a Novi robotics lab.

On August 13, DeepSeek open-sourced its agent harness. Twenty-two thousand GitHub stars in an hour and a half; past sixty-five thousand within a day. The README says:

Everything is a plugin. Every run is traceable.

This is fascinating — I honestly didn’t expect DeepSeek to go this far. And the first thing it made me think about wasn’t code. It was robot commissioning — the line item that eats nearly forty percent of an industrial automation project’s cost — and how it ought to be done. Because that sentence says, in the language of software, something the robot-commissioning trade has been doing for thirty years without ever giving it a name.

First, What a Harness Is

The core loop of an agent is simple: the model reads context, decides which tool to call, the tool runs, the result goes back into context, look again. A few dozen lines gets you a working loop. The hard part is the ring around the loop: who allows it to call this tool? What gets checked before the call? Who confirms the result afterward? When something goes wrong, how do you replay what it saw at the time?

That ring is the harness. The word means, literally, the tack you put on a horse — the gear that lets a fast animal be controlled, stopped, and traced. The horse is the model. The harness is the discipline around it.

DeepSeek’s version is radical: there is no privileged core. The model adapter, the tool registry, the session log, the agent loop itself — all plugins. Adding a capability doesn’t mean editing the core; it means mounting a plugin beside the others. But “everything is a plugin” as a slogan isn’t what I want to talk about. What matters to me are the two mechanisms underneath.

First: checks can be layered outside a tool without touching the tool. The Cordis framework underneath has something called waterfall — essentially around-middleware. Each listener receives (…args, next). It can inspect the arguments and then call next() to let the call through; it can decline to call next() and short-circuit; or it can take the downstream result, alter it, and pass it back up. The lifecycle document describes tool execution as “ordered pre, concurrent execute” — pre-checks run in order, and only what passes runs concurrently.

Which means: adding a new safety check to a tool does not require opening that tool’s source. Checks are external, and they stack. Hold onto this — on the robot side it becomes a matter of life and death, and I’ll come back to it.

Second: every run can be replayed. Everything the model sees — system prompts, reasoning, tool calls and results, subagent scheduling, every context injection — goes into an append-only session log. Resume, fork, search, and replay all operate on the same event stream. When something breaks, you can see exactly what it saw and why it decided what it did.

Put plainly: the parts that build capability (model, tools) and the parts that constrain it (checks, log) are structurally separated, and the second can grow independently of the first.

Three Rounds of Collision Checking, and None of Them Included the Part

A while ago I took a real, large die-cast structural part and, using an AI agent, ran the entire chain offline — from CAD to a two-arm robot deburring path. Parting-line pickup, curve sampling, tool-point generation, dual-arm layout optimization, arm assignment, visualization — all the way to watching the robots move frame by frame on screen.

It ran. But running wasn’t the real takeaway. The real takeaway was watching how the errors got found.

The process surfaced a dozen or so substantive defects. Most of them I caught by glancing at the screen: the part was lying upside down; the burr direction pointed inward; tool points flew a meter outside the part; the two arms kept trading off back and forth along one segment, which is unworkable as a process. A handful were caught by the system itself, because something didn’t match real data.

The one that bothered me most was collision checking. The agent did three rounds. All three passed. All three left the workpiece out of the collision model — it only checked whether the robot would hit itself. Deburring means reaching into the part’s cavities; the most typical interference is hitting the part. Three rounds of self-checking missed the most basic collision in the trade.

A check designed by the agent that wrote the code cannot catch the failure modes that agent didn’t think of.

This isn’t about the model not being smart enough. Swap in a stronger model and it writes prettier collision checks — that still only cover the cases it thought of. The builder’s blind spots get copied, intact, into the verification the builder writes. That’s a structural problem, not a capability problem.

The old hands have always known this — they just don’t say it this way. Anyone who has commissioned a robot knows the ritual: teach, dry run, single-step, low speed, full speed. Every step is a check independent of the person who wrote the program. The dry run checks the trajectory; single-step checks each point; low speed checks the dynamics. What the ritual is really saying is: the brain that wrote the program is not to be trusted, so wrap it in layer after layer of checks that don’t depend on it.

That’s a harness. The shop floor was using one for thirty years before software gave it a name.

Why a Robot’s Harness Has to Be Harder

Up to here the two worlds look like they’ve merely arrived at the same place. But the robot side has a boundary the software world doesn’t.

Every error in my exploration — the upside-down part, the tool point a meter out, the missed collision — what did it cost? Rerun. A few minutes. In the world of pure software agents, failure is cheap, reversible, and infinitely retryable, so you can build boldly, fail fast, fix later.

The moment that program goes down to a real robot, the tool point a meter out is no longer a bug. It’s a crash. A bent fixture, a wrecked end effector, a stopped line — and, on a bad day, someone hurt. The fault tolerance of the offline stage does not exist on the production line.

That boundary changes the design requirements for the harness. At least three of them.

One: verification must be independent of generation. In software, letting the agent write its own tests is an acceptable shortcut — if the tests miss something, you run one more round. In robotics that shortcut is the direct cause of accidents. Real verification has to come from outside the agent: in-line inspection, comparison against real-machine measurement, or a second, fully independent implementation for cross-checking. Verification coverage must not fall below automation coverage. Every ring you add to automation enlarges the region where the system can quietly produce wrong results; verification has to keep pace, or you’re only widening the blind spot.

Two: the human’s position is structural, not transitional. Most of my dozen-odd defects were “glance at the screen and see it.” That kind of perception — is the part oriented right, is the direction flipped, does the path look sane — no automation replaces today, and I doubt it should any time soon. The right division of labor: AI owns the speed of building and iterating; humans own perception and anchoring to reality. The first can be accelerated without limit. The second cannot be dropped. Some semantics can only be supplied by a person; the job is to make that fast (one click instead of an hour by hand), not to eliminate it.

Three: every time you add a piece of automation, add a check that can independently catch it being wrong. I now write this sentence into every project charter. It sounds like common sense, but common sense without structural support doesn’t survive the second project — under deadline you add the feature first and leave the check for “next time.” The reason the harness’s waterfall mechanism caught my attention is exactly that it moves this discipline from relying on conscientiousness to relying on structure: checks are external, stackable, and addable without modifying the tool. Get the structure right, and the discipline holds.

The Asset Isn’t the Software. It’s the Harness.

Before that exploration, I thought the output would be “a piece of software that automatically generates robot paths.” Afterward I understood the software itself was worth little. What was actually valuable were the few lines inside each tool that read: “you only know to write it this way after you’ve hit the wall.”

A certain coordinate frame is off by a fixed transform — miss it and you’re off by a few degrees the whole way, with symptoms that point misleadingly elsewhere. A certain geometry can’t use the standard simplification under this kind of operating condition, or it false-alarms end to end. A certain degree of freedom is redundant, and locking it throws away a dimension for nothing.

These things share one trait: they can’t be derived from documentation or experience. They can only be hit. And once hit — and encoded into a check — the next part never pays that tuition again. The compounding isn’t in the features. It’s in the constraints that stop charging you tuition.

So the asset isn’t the software. It’s the harness. And a harness can only be fattened inside real projects. R&D detached from projects produces things that are self-consistent and wrong — because nobody knows what to check.

DeepSeek’s line, translated for the shop floor, comes out like this: capabilities are pluggable; discipline must leave a trace. However fast the builder runs, the verifier cannot be itself.

Software just wrote that law into code. Robotics has been learning it, one wrecked fixture at a time, for thirty years.

Subscribe now

Walk into any die casting plant and the loudest corner isn’t the casting machines. It’s the deburring benches. Sparks, dust, anti-vibration gloves — a row of workers hunched over, running the edge of every single casting by hand.

And the bench is never just the bench. It adds a material-handling loop, a line-side buffer, a haze of dust over half the shop — and, less visibly, it ties up working capital in parts that sit waiting for hands.

Three numbers from that corner are worth remembering: annual turnover at the deburring station, 35%. Time for a skilled worker to finish one structural casting, about 60 seconds. And zero — the number of times, in the past thirty years, this station has been fully automated away.

A plant manager once pointed at one of his veterans and told me: “He’s worth three men. The others are no use.” I looked at the man’s weathered face and felt something I couldn’t quite name.

Robot welding is everywhere. Robot painting is everywhere. Robot palletizing is a commodity. So why is the dirtiest, most injury-prone, least wanted job in the shop the last one still done by hand?

The answer isn’t that robots aren’t good enough. The answer is in the physics of the burr.

A Burr Is the Casting Process’s Fingerprint

Start with where burrs come from. In high-pressure die casting (HPDC), molten aluminum fills the cavity in tens of milliseconds at tens of megapascals. That pressure slams the metal into every gap the die offers — parting line, ejector pin clearances, vent channels. The thin layer that squeezes in and freezes there is flash.

Which means the thickness of the flash is essentially a photocopy of the die’s clearances. And those clearances are not constants: the die wears under thermal cycling and high-pressure scouring, clamping force drifts, gaps grow.

Today’s flash distribution is not the flash distribution three months from now. A burr is not a feature. It is a statistical distribution — and the distribution drifts.

Low-pressure die casting (LPDC) is a different world. Wheels are the classic case: slow fill, low pressure, and the parting-line flash is far milder. But the burrs don’t disappear — they change battlefield. Now they live on the cut faces where gates and risers come off, and at the exits of machined holes. Machining burrs form differently, too: at the instant a cutter exits an edge, the material isn’t sheared off — it’s pushed out. That rolled-over rim is the residue of plastic flow.

One word, “burr,” and on high-pressure versus low-pressure parts it means two different physics, two morphologies, two distributions. Don’t let the single word fool you — the same way “crack” is one word for many different animals.

The Human Hand Is an Underrated Machine

Why is the veteran so good? Take the skill apart and the hand is doing three things at once: fingertips sensing force in real time (more stock, more pressure), eyes inspecting in real time (clean or not — one glance), wrist re-planning online (this part’s flash sits two millimeters left of usual, so the path shifts with it).

A single machine with force control, vision, and online re-planning, closed at millisecond rates — in robotics that’s a frontier research topic. At the deburring bench it’s the first week of onboarding.

But the human cost lives in those same three things. Every worker’s definition of “clean” is different, and one worker’s definition differs between morning and afternoon. Eight hours of vibration and dust treats the body as a consumable. And 35% turnover means that just when you’ve finally taught everyone the standard, they leave.

The hand wins on adaptability and loses on consistency — the goal of automation was never to imitate the former, but to keep it while buying the latter.

Three Walls: Why Robots Still Can’t Deburr

Wall One: CAD Is a Fiction Everyone Agrees to Believe

Where does a robot’s path come from? From CAD. But a casting is not its CAD model. Solidification shrinkage pulls the dimensions in, uneven cooling warps the part, and die wear makes every batch drift slowly in shape. Between the physical part and the nominal model runs a gap — and the width of that gap changes on its own.

Cutting to the model gives you exactly two outcomes: grinding air, or gouging parent metal.

The direction of the way out isn’t hard to point at: measure the part in your hand, not the one you designed. What’s hard is doing that inside a production takt — which is a topic for another article.

Wall Two: Force and Stock Are Each Other’s Unknowns

Grinding is a game of force: heavy pressure for thick stock, light touch for thin, and getting it wrong either leaves the burr or eats the part. But each part’s stock distribution is unknown before you grind it — it is the drifting statistical distribution itself.

Whether the spindle is compliant or rigid, the traditional approach can only aim at the average: never over-cutting, but guaranteed to leave residue somewhere. That’s not a tuning problem. It’s the built-in strategy of conventional robotics.

Fix the force and the stock won’t cooperate; fix the path and the part won’t cooperate. That’s why teach-pendant deburring robots look great at trade shows and get sent back to manual within three months on a real line: they assume a world that doesn’t drift.

Wall Three: You Have to See It First

You can’t remove a burr you can’t find. And “seeing a burr” is not optically trivial: on matte aluminum, a flash root microns deep and millimeters long sits tangled in the same image with texture, oil stains, and shadows. What a human eye separates in one glance, a camera often can’t — there’s an entire discipline in that sentence, which I’ll leave closed today.

The three walls are three faces of the same enemy: variation. Position varies, stock varies, appearance varies — and the entire estate of classical automation is built on things not varying.

The Shop Floor Produces a Health Report Nobody Reads

Here’s something most plants haven’t noticed they own.

The veteran compensates every single day: this batch’s flash runs thicker than last week’s, so the hand bears down a little more; the left side runs heavier than the right, so the path drifts left. None of these compensations is recorded. They evaporate at the end of the shift.

But record them — each part’s correction relative to the nominal path, laid out over time — and you get a curve. And that curve is narrating the health history of the die: wear accelerating, clamping force decaying, an ejector pin due for replacement.

Corrections are not operator noise. They are the die’s electrocardiogram. The shop floor produces a health report every day — nobody is reading it.

What that observation is worth depends on what you connect it to. Today I’m only putting the observation itself on the table.

What It Would Take to Actually Automate This Station

Turn the three walls around and the conclusion writes itself. A deburring system that deserves the word “automated” must answer three questions for every individual part: Where are this part’s burrs? (Inspection, not assumption.) What force did it use and what path did it take? (Adaptation, not playback.) And after grinding — is it clean? (Re-inspection, not prayer.)

Inspection and rework have to be two steps of one closed loop, not two machines on a line. The eye tells the hand where to grind; the hand finishes and the eye looks again. It sounds like a truism — and most solutions on the market die precisely by splitting that truism into two separate procurement packages.

The burr is the smallest part-level problem in the shop, and the most everyday incarnation of the monster called variation. Whoever tames that drifting distribution understands half of manufacturing automation — the other half is making the taming cheap enough to be worth doing.

That’s the next article.

First Principles Manufacturing — Dispatches from a Novi robotics lab.

Subscribe now

My RTX 3080 can run Battlefield only because it never renders the whole battlefield. The explosion behind you, the collapsing building, your teammate’s body — none of it gets drawn until the instant you turn your head. This is called frustum culling, and no player ever catches it in the act, because “catching it” is itself a head turn.

Anyone who has written a game engine knows a few more tricks from the same family. Cap the speed at which information travels, so no local region overloads the compute budget. Let two NPCs a thousand miles apart share one memory address — change one, and the other changes with it.

And of course, tricks sometimes fail. Every gamer has seen clipping: collision detection only runs a few checks per frame, so with enough speed and a nasty enough angle, half your body sinks into a wall and a bullet kills you through solid cover.

The trouble is that every one of these — the glitch included — has a counterpart in physics. And not the hand-wavy kind.

The engine tricks, found in nature

Leave a particle unobserved and it exists as a superposition of probability waves, as if the system can’t be bothered to assign it a definite position. Put a detector in place and the wavefunction collapses; the particle instantly acquires a trajectory. This is not a metaphor — it is what double-slit and delayed-choice experiments have confirmed, over and over.

The speed of light is hard-capped: 3×10⁸ m/s, and no information gets past it. Space and time aren’t infinitely divisible either — below the Planck length (1.6×10⁻³⁵ m) and the Planck time (5.4×10⁻⁴⁴ s), current physics simply stops working. Pixels and refresh rate: check.

The shared memory pointer? That’s quantum entanglement: measure one of two distant particles, and the other’s state is fixed at once. Einstein called it “spooky action at a distance” and refused to believe it. The 2022 Nobel Prize in Physics went to the three people who proved it with Bell tests.

And clipping? Physics calls it quantum tunneling. A particle facing a barrier that classical mechanics says it can never cross has a definite probability of simply appearing on the other side. This is no laboratory curiosity: the Sun has burned for 4.6 billion years because protons tunnel through the Coulomb barrier — classically, it couldn’t ignite at all — and the flash memory in your phone writes every byte by letting electrons clip through a wall.

Reality’s collision detection drops frames too — and it does so unapologetically.

Culling, a frame-rate cap, a minimum resolution, state sync across any distance, even clipping. The engineering fingerprints are all there. At this point, “we live in some advanced civilization’s game console” starts to look hard to refute.

Do Physicists Themselves Buy It?

Which raises a better question. Nobody knows this evidence better than physicists — they ran the double-slit experiments, they computed the Planck scale, they awarded the Nobel for the Bell tests. Do the people who handle these “engineering fingerprints” every day believe the simulation hypothesis?

In 2016, the American Museum of Natural History devoted its Asimov Memorial Debate to exactly this question, moderated by Neil deGrasse Tyson. The disagreement on stage was startling.

Tyson himself put the odds at roughly even. String theorist James Gates told the room something that made it go quiet: inside the equations of supersymmetry, he had found a set of error-correcting codes — the same class of binary codes that keep your browser’s data transfers intact, embedded in the mathematical structure describing elementary particles. In his words, it made it hard for him to laugh off The Matrix. Sharing the stage, Lisa Randall put the probability at “effectively zero.” Sabine Hossenfelder later went further and flatly called the hypothesis pseudoscience.

The interesting part isn’t how hard they argued. It’s that when you press the skeptics on why they don’t believe, their reasons converge. Not philosophical taste. Compute.

That Server Cannot Be Built

Suppose there really were an external server running our universe. How much memory would it need?

The state space of a quantum system grows exponentially with particle count. Three hundred entangled electrons span a state space of dimension 2³⁰⁰ — about 10⁹⁰, already more than the number of atoms in the observable universe (about 10⁸⁰). Three hundred electrons. A glass of water holds 10²³ times more.

And that’s just storage. In 2017, Zohar Ringel and Dmitry Kovrizhin showed in Science Advances that for certain quantum systems with gravitational anomalies (electron systems exhibiting a thermal Hall effect, for example), classical simulation slams into the “sign problem”: the cost blows up exponentially, and the obstruction is provably unavoidable. It’s not that our algorithms aren’t clever enough — the classical route itself is closed. The media headlined it as “physicists prove we don’t live in a simulation,” which oversells it. But it did nail one thing down: simulating our universe’s physics on classical hardware fails even in principle.

So to fully simulate our universe by classical means, the world hosting that “server” would have to be vastly more complex than ours. That explains nothing — it just pushes the question out one level: who simulates that world? Occam’s razor swings cleanly here. Adding a “programmer” multiplies entities; it doesn’t reduce them.

It from bit

Physicists offer an answer that is both more economical and much stranger: the universe doesn’t need to run on any server, because it is the machine. What look like “optimization artifacts” aren’t anyone cutting corners — information processing is simply how this world operates at the bottom. John Wheeler compressed the position into three words: it from bit. Matter doesn’t come first with information derived from it; information comes first, and spacetime and matter grow out of it.

That sounds mystical. It isn’t — there are concrete technical threads behind it.

Three Threads

Space may be stitched from entanglement. In 2013, Maldacena and Susskind proposed the ER = EPR conjecture: quantum entanglement between two particles (EPR) is geometrically equivalent to a microscopic wormhole (an ER bridge). If it holds, three-dimensional space is not a box that contains things — it is a mesh woven from the entanglement of vast numbers of qubits. Cut every thread of entanglement in a region, and “space” there falls apart. To be clear: this is still a conjecture, not a theorem. But quantum gravity researchers take it seriously.

Time may be a local illusion. Try to write one quantum state equation for the entire universe and you get the Wheeler–DeWitt equation:

H^∣Ψ⟩=0H^∣Ψ⟩=0

There is no time variable in it. Globally, the universe’s total quantum state just sits there; nothing happens. Then what is the flow of time we experience? Page and Wootters offered an answer in 1983: time is a relation between subsystems. You — one subsystem — read off the experience of “evolution” through your entanglement and decoherence with the environment. No river globally; the sound of running water locally. The approach remains contested, but “time is emergent, not fundamental” is no longer heresy.

Three dimensions may be a projection of two. A black hole’s maximum information content scales not with its volume but with its surface area — Bekenstein and Hawking worked that out in the 1970s, and it is where the holographic principle starts. AdS/CFT duality later gave it an exact mathematical form: a D-dimensional spacetime with gravity is equivalent to a quantum field theory without gravity on its (D−1)-dimensional boundary. Honestly stated: the duality is rigorous in anti-de Sitter space, and our universe is de Sitter — whether it transfers is an open problem. But the core fact stands: gravity and spacetime geometry can be fully translated into information dynamics on a boundary, and the mathematics checks out.

Three threads, one direction: spacetime is not the stage. It’s the plot — what a quantum information network looks like at coarse grain.

Why Quantum Computers Are a Different Thing

Once you see this layer, the meaning of quantum computing changes.

Most introductions call it “a computer that calculates faster,” which misses the point. A classical computer uses transistor 0s and 1s to approximate the equations of physics — doing physics with math. A quantum computer uses the superposition and entanglement of its own qubits to evolve isomorphically with a physical system — doing physics with physics. Feynman said it plainly in 1981: nature isn’t classical, and if you want to simulate nature, you’d better make your machine quantum mechanical.

Three hundred electrons break classical simulation. For a quantum computer, 300 logical qubits against 300 electrons is a 1:1 mapping — no exponential blowup. That’s why in 2022 a Google team used a quantum processor to simulate the dynamics of a traversable wormhole (yes, the ER = EPR thread). A quantum computer isn’t just a tool. It is, so far, the only machine that speaks the universe’s native language.

The Ending

So where does the simulation hypothesis go wrong? Not in its observations — in its conclusion. It sees the right phenomenon — reality’s foundations really are saturated with information processing — and then bolts on a redundant explanation: a computer outside.

Physics offers a cleaner picture: there is no outside.

The universe weaves space from entanglement, manufactures time’s direction from decoherence and entropy, and freezes probability into fact through measurement. We are not NPCs being rendered. We are part of the computation itself — every observation is one step in this machine’s evolution.

It’s less romantic than the game-console story. But it has one enormous advantage: it might be true.

First Principles Manufacturing — Dispatches from a Novi robotics lab.

Subscribe now

I. The Demo Was Impressive. But Can It Deburr?

The demo was impressive. A humanoid robot walks to a cabinet, opens the door, takes out a cup, and places it on the dining table. The whole sequence flows like a skilled housekeeper. The presenter’s face says “this is the future.”

I waited for him to finish, then asked one question: can this robot deburr?

The air went quiet for two seconds. He said: deburr what?

I explained: a workpiece comes out of the die-casting mold with 0.3mm burrs along the edge. You need a rotary cutter to trace the edge and shave them flat. The requirement: don’t cut into the workpiece body, and don’t miss any burr. Precision ±0.3mm.

He said: it should… probably work? Train it some more.

That “should work” isn’t a few training runs short. It’s a full order of magnitude of physical reality short.

II. Industrial Robots Have Two Precisions — And They Differ by an Order of Magnitude

Most people don’t know that an industrial robot’s datasheet lists two precisions, but most only ever see one.

Precision Type Definition Typical Value Determining Factors Repeatability Deviation when reaching the same target multiple times ±0.02–0.05mm Encoder resolution, servo response Absolute Accuracy Commanded pose vs. actual reached pose ±0.5–0.8mm, poor ones ±2–6mm DH calibration, link thermal deformation, gear backlash, base rigidity

No need for an abstract example — take one of the most common mid-range arms on the shop floor: the ABB IRB 1200. Its official datasheet lists repeatability as 0.025mm — printed right where you’ll see it. But scroll down the same page, and the ISO 9283 linear path accuracy (AT) is 0.53mm.

Same robot, same datasheet, two numbers that differ by 20×.

Why such a gap? Because absolute accuracy is full-chain error accumulation. DH calibration error, link thermal deformation, gear backlash, base rigidity — every link injects error into absolute accuracy. Repeatability only cares about “returning to the same place”; absolute accuracy demands “going to the place the command names.” Completely different difficulty. There’s a rule of thumb in the field: a robot’s absolute accuracy is typically 20× or more worse than its repeatability. For large arms, or uncalibrated ones, ±2–6mm is common — one calibration study pulled absolute error down from 6.3mm to 0.5mm, which tells you how large the raw error was.

And here’s the more damning fact: most manufacturers only publish repeatability — they never disclose absolute accuracy. That pretty “±0.02mm” on the spec sheet is almost always repeatability. Absolute accuracy is the number they’d rather not print.

III. The “Secret” of Existing Industrial Solutions: Using Repeatability for Precision Processes

So how is industrial grinding actually done? The answer: absolute accuracy is never used.

Teaching (jogging): A person drags the arm to the point and records the joint angles. During execution it plays back perfectly — error only ±0.05mm. The human is the “precision sensor,” feeling and seeing to set the trajectory exactly.

CAD offline programming + visual guidance: First use vision to locate the workpiece (establish a workpiece coordinate frame), then “paste” the pre-programmed trajectory onto that frame. Absolute accuracy only handles “rough approach”; precision relies on “relative positioning + repeatability” as the safety net.

Both methods share one core sentence: make the robot return to a place it has been, not travel to a coordinate it has never visited. This approach has run for forty years. Not because it’s outdated, but because physically, it’s the only path that works.

IV. The Blind Spot of Embodied AI Paradigms: All “Absolute Positioning” Thinking

Now look at the mainstream embodied AI paradigms:

VLA models (RT-2, OpenVLA, π0): End-to-end regression of end-effector pose or joint angles — the output is an absolute target.

LLM planners: Output spatial coordinate sequences — absolute coordinates.

Vision-action models: Look at the target object directly, output the action to reach it — no concept of “workpiece coordinate frame + relative trajectory.”

All these paradigms share one implicit assumption: that the robot can precisely reach the target pose the model gives.

One detail says it all: search through these models’ papers and you won’t find a single mm-level positioning-accuracy metric. OpenVLA, π0, and RT-2 all report task success rates — π0 hits 80–95% on trained tasks, RT-2 hits 62% on novel objects. The recent VLA benchmark surveys evaluate success rate, generalization, instruction-following. Not one uses “end-effector landed within ±0.x mm” as an acceptance threshold.

This isn’t an oversight — it’s the paradigm blind spot: the entire academic evaluation framework has no “submillimeter accuracy” dimension at all. Yet for industrial precision processes, that’s the very first gate. ±0.5–2mm absolute accuracy against a ±0.3mm process requirement is physically impossible.

V. Then Why Does the Demo Look Flawless?

Because the tolerance of household scenarios and that of precision processes differ by two orders of magnitude.

Opening a cabinet, grabbing a cup, folding laundry, putting a plate in the sink — these have tolerances around ±2–5cm. A robot’s ±2mm absolute accuracy has a full two orders of magnitude of margin here; it can’t go wrong. Of course the demo flows.

But nobody deburrs in a demo. Not because they didn’t think of it — because it’s physically impossible. The moment the process requirement drops to ±0.3mm, those two orders of magnitude of margin flip into two orders of magnitude of deficit.

So every stunning embodied-AI demo you see lands in a high-tolerance scenario: flexible grasping, assembly pre-positioning, logistics sorting. Which is exactly the reverse proof that the precision wall exists — what can be demoed doesn’t need submillimeter; what needs submillimeter never gets demoed.

VI. Where the Conflict Happens

Put the two lines side by side:

• Grinding, deburring, weld-seam tracking, precision assembly — process precision is all in the 0.1–0.5mm range

• Embodied AI runs on ±0.5–2mm absolute accuracy

The precision magnitude overlaps with — or is worse than — the process requirement. This isn’t solved by “training a bit more.” It’s the physical boundary of mechanical structure: gear backlash doesn’t shrink because the model got bigger, link thermal deformation doesn’t vanish because the dataset grew.

VII. You’ll Probably Push Back Like This

I’ve voiced this argument enough to have heard nearly every objection. Point by point:

VIII. The Solution: Hierarchy of Accuracy

I’m not against embodied AI. I’m against using it at the wrong level.

The correct architecture is a three-layer relay, letting each layer do only what it can physically do:

Layer Capability Responsible Party Precision Upper (Semantic Decision) Identify workpiece, judge defects, select process Embodied AI / VLA Precision not required Middle (Visual Re-localization) Sub-pixel template matching, establish workpiece frame Industrial vision ±0.01mm Lower (Physical Execution) Replay pre-calibrated trajectory in local frame Industrial robot ±0.02mm (repeatability)

This is isomorphic to nuclear engineering’s “defense in depth”: each layer’s capability boundary is clearly drawn, never expecting a single system to do it all. A reactor doesn’t rely on one barrier to catch every risk, and a precision process shouldn’t rely on one end-to-end model to catch every micron.

Embodied AI is right at the decision layer. Embodied AI is wrong at the precision layer. Put it at the right level and it’s the smartest layer in the stack; put it at the wrong level and it can’t shave a single 0.3mm burr.

(Whether that middle-layer sub-pixel visual loop can stably reach sub-pixel accuracy, our lab is still validating — no final answer yet. But the layering logic itself is settled.)

IX. Advice for Practitioners

For embodied AI entrepreneurs:

• Don’t pick precision processes. Pick high-tolerance scenarios: flexible grasping, assembly pre-positioning, logistics sorting.

• Your edge is understanding and decision-making, not physical precision. Leave the precision layer to the industrial methods proven over forty years.

For industrial practitioners:

• Don’t be intimidated by demos. Your “teaching + visual re-localization” stack is still correct — the physics hasn’t changed.

• Embodied AI isn’t here to replace your execution layer; it’s here to add a decision layer. See that clearly and you’ll know what to buy and what to skip.

First Principles Manufacturing — Observations on physics, economics, and cross-cultural engineering from a nuclear engineering PhD on a Michigan shop floor. Subscribe:

Subscribe now

I. The Walmart Self-Checkout: My First Cognitive Crack

Before coming to the US, I had a preconception about electronic payments here: China’s QR-code system is so ubiquitous that America must lag behind.

So when I first walked into a Walmart, I wasn’t asking “Do they have self-checkout?” I was thinking, “They probably don’t have much self-checkout, since electronic payment isn’t as developed.”

The result?

Self-checkout is the default. Not a pilot program. Not a marginal option. The primary option. Target, too. Home Depot, too.

My first reaction: “Americans are pretty advanced too.”

But after living here longer and observing more, I realized this isn’t about “advanced” or “behind.” This is two completely different underlying logics.

II. The One Person at AutoZone: The Extreme of Autonomy

Last week I went to AutoZone to buy a part. One employee in the store, running around: answering phones, checking inventory, giving advice, checking out.

Not understaffed. Designed this way.

This employee isn’t “forced to do three people’s jobs.” He’s designed as “one person who can handle the full process.” The system is built around him, not cutting him into a cog.

The same pattern everywhere:

• Burger joint: one person grills the patty, adds veggies, spreads sauce, packs

• Pizza shop: one person kneads dough, adds toppings, fires the oven, slices

• BBQ place: one person starts the fire, marinates meat, flips on the grill, plates

Every position is a closed-loop system: input → process → output. One person is one autonomous unit.

III. Chinese Entropy Reduction: Deconstructing Complexity to the Extreme

Contrast with a Chinese restaurant kitchen:

• One station for prep

• One station for wok

• One station for plating

• One station for dishes

A single dish passes through four or five hands. Each person handles only one entropy-reduction step: transforming chaotic raw materials into more orderly semi-finished products, eventually assembled into the final dish.

This isn’t inefficient. This is another underlying logic: through extreme division of labor, reduce the system’s entropy (disorder) to the minimum.

China’s automation follows the same logic:

• Foxconn’s production line: each station does one motion

• Meituan food delivery: order, pickup, delivery—three people complete one loop

• QR-code payment: deconstruct the complex act of “transaction” into three frictionless steps: scan → deduct → notify

What China is doing is entropy reduction.

IV. Two Worldviews: Maintain vs. Reconstruct

Walmart’s self-checkout isn’t “using machines to replace people.” It’s “returning the decision-making power of checkout to the customer.”

China’s unmanned supermarkets aren’t “giving customers freedom.” They’re “reducing the entropy of the transaction process to zero.”

V. Implications for AI and Automation

This divide directly shapes how we design AI products.

For Western markets, the question AI products must answer:

“How can AI help this person make better decisions?”

• Copilot mode: AI assists, human makes final call

• Augmentation tools: AI processes information, human handles judgment

• Autonomous units: each node has complete decision-making capability

For Chinese markets, the question AI products must answer:

“How can AI eliminate friction in this process?”

• Replacement mode: AI completes directly, human only handles exceptions

• Process reconstruction: deconstruct human steps into AI-executable ones

• Entropy-reduction system: input → AI processing → output, no human decision points in between

Not saying one is better. Saying if your product logic doesn’t match the market’s underlying worldview, you’ll die badly.

VI. A Concrete Manufacturing Example

At our lab in Novi, we work on robotic grinding.

The first question from American customers is usually:

“Can this system help my operator make better decisions about when to adjust the toolpath?”

The first question from Chinese customers is usually:

“Can this system run fully automatically so I don’t need an operator?”

Same technology. Two ways to sell it.

If we pitch “fully automatic, unmanned” to American customers, they feel you’re stripping away human value.
If we pitch “human-machine collaboration, enhanced decision-making” to Chinese customers, they feel you’re selling a half-finished product.

It’s never that you can’t do it because you don’t work hard. It’s that you can’t do it because you don’t realize it.

VII. Vision Determines the Future

After recognizing this divide, I looked back at my own product design and found many blind spots.

I used to think “the higher the automation, the better.” Now I know that in the American market, “the higher the autonomy, the better” is the correct North Star metric.

Not replacing people. Amplifying people.

Not eliminating human steps. Making human steps more valuable.

This cognitive shift is more important than any technical breakthrough. Because it determines:

• Your product definition

• Your sales pitch

• Your organizational design

• Your technical roadmap

Vision determines action. Perspective determines the future.

First Principles Manufacturing — Observations on physics, economics, and cross-cultural engineering from a nuclear engineering PhD in a Michigan shop floor. Subscribe:

Subscribe now

I had a defensible thesis. Humanoid robots in factories are theater. Real production lines run on dedicated automation: SCARA arms, gantries, custom end-effectors, and the unglamorous workhorse most engineers underestimate — the fixture.

A fixture is a piece of tooling that holds a part in exactly the right place so the next operation — a weld, a grind, a torque check, a measurement — happens repeatably. When a CNC station hits 60 parts/hour, it’s the fixture, not the robot, doing the geometric work. The arm just executes pre-programmed motion against a known datum.

For five years I argued: humanoids can’t beat fixtures. Lower precision. Higher cost per minute. Fewer cycles per shift. Show me a process where a humanoid replaces a 5-axis fixture and a Fanuc, and I’ll show you a marketing video.

I was wrong about the comparison.

What fixtures actually cost

Fixtures don’t show up cleanly on a P&L. Tooling capex is a line item; the dynamics are not.

A serious fixture set for a single new part runs $80K–$300K in tooling, plus 8–14 weeks of design, fabrication, debug, and trial-run cycles. That’s before you ship a single unit. It’s why high-mix, low-volume manufacturing in the US has been losing to Chinese contract manufacturers for two decades — Chinese suppliers don’t pay less per fixture; they amortize fixtures faster across more SKUs and absorb thinner tooling-funded margins.

The hidden cost is changeover. Every fixture swap pulls a line down. In a high-mix shop, fixture-driven changeover eats 15–25% of available production hours. That’s the line that bankrupts US contract manufacturers chasing flexible orders.

Now reread the humanoid pitch with that frame:

A general-purpose end-effector that holds, presents, orients, and inspects parts — without dedicated tooling per SKU — is not replacing a worker. It’s replacing the fixture.

That’s the thesis I should have stress-tested in 2021. I didn’t. This week I did.

The week the numbers lined up

Five signals hit my feed in seven days, all pointing the same direction.

Schaeffler — the German bearings and automotive supplier — committed to 1,000 Hexagon humanoids on production lines by 2032. Not an R&D pilot. A line-side deployment plan with a public number, in partnership with Hexagon and VinDynamics.

1X opened a US factory and announced 10,000 home robots in year one. Set aside whether year-one is hit. The signal is vertical integration on US soil, with Bloomberg confirming the target in writing.

Japan Airlines started humanoid baggage sorting at Haneda. Airports are factories — sorted parts, variable mix, tight cycle. JAL didn’t pick humanoids because they’re fashionable. They picked them because the alternative — a custom sorter for every bag geometry — failed economics.

Figure published stability data: their humanoids now stay balanced after losing single or multiple joints. That’s not a marketing reel. That’s a control-systems claim that, if it survives production hours, narrows the gap with fixed-base arms by an order of magnitude.

And the punchline: Createme’s CEO went on the record this week — deformable-material assembly is the real test for physical AI. Apparel, soft seals, gaskets, harnesses. Exactly the parts fixtures handle worst. He’s right. And he’s saying it because his customers are asking.

Five data points pointing the same direction in seven days isn’t noise. It’s the early phase of a curve where unit economics stop being a theoretical argument.

The American brutality that built this

Here’s the part I want US founders to hear and Chinese policymakers to read.

In 24 months Figure AI moved from a $500M valuation to ~$39B. Meta acquired Assured Robot Intelligence to staff up its humanoid program. Five US companies — Tesla Optimus, Figure, 1X, Boston Dynamics, Apptronik — are independently driving humanoid hardware costs from millions per unit toward $50K–$150K.

Five companies because in the US market, capital is allowed to fund five bets when one will be right.

China sees this and is reacting accordingly. This week the Chinese government blocked Meta’s $2B acquisition of Chinese AI startup Manus. The Frankfurter Allgemeine Zeitung reported it days before an expected Xi-Trump Beijing summit. Beijing is no longer worried primarily about US technology coming in; it’s worried about Chinese AI know-how going out.

The US system isn’t gentle. Most of those five humanoid companies will fold in 36 months. The ones that survive will absorb the survivors’ best engineers and IP for ten cents on the dollar. People who call this “brutal” miss the point: the brutality is the selection mechanism, and the selection mechanism is the moat. China can fund five companies; it cannot, by design, kill four of them with the speed America does.

Both systems will produce humanoid platforms by 2030. The American platform will have stronger unit economics because four other versions of it died first.

VLA: the brain that makes fixture replacement real

Hardware alone never replaces fixtures. The reason 2021 humanoid demos failed is the same reason 2018 and 2014 demos failed: no model could turn “pick this connector and seat it in that harness” into closed-loop motion against an unmodeled object.

That problem now has a name: Vision-Language-Action models (VLA).

This week alone:

• Three new VLA architectures hit arXiv (LaST-R1, MotuBrain, PRTS), all targeting closed-loop manipulation under physical uncertainty

• An open-weights 1.6B-parameter robot foundation model launched (LDA-1B), trained on 30,000+ hours of heterogeneous human and robot interaction data

• PND-0 VLA was demonstrated live on a humanoid at CCMT 2026 doing flexible 3C manufacturing tasks

• And — the part that matters most for democratization — a $15K open-source humanoid platform shipped that runs on open-source VLA weights

First principles: capability shows up as the product of body × brain × data. For five years bodies got cheaper while brains stayed dumb. This is the year all three terms moved together.

The fixture replaces faster when the brain understands the part.

What I’d tell 2021-me

If you’re a manufacturing engineer reading this with the same skepticism I had: I don’t need you to believe humanoids will replace your Fanuc cell. I’m not saying that. I’m saying:

1. Stop comparing humanoids to dedicated automation. Compare them to the fixture you would have built for that next 10K-unit run.

2. Run the changeover math. If you’re losing 15–25% of production hours to fixture swaps, a $50K–$150K humanoid that handles three SKUs without retooling has a payback window measured in months, not years.

3. The bottleneck stops being hardware and starts being the data you’re collecting on real parts. Whoever owns the data owns the deployment.

Technology is taking giant strides this week. The strides that matter are the ones where the humanoid stops fighting the fixture and starts replacing it.

Subscribe now

First Principles Manufacturing — physics, economics, and shop-floor reality from a nuclear-engineering PhD turned industrial-AI practitioner. Subscribe at firstprinciplesmanufacturing.substack.com.

Share

The setup

A team in China was stuck.

They were running fully-automated hand-eye calibration — solving for the 4×4 rigid transform between a robot’s end-effector frame and the camera’s frame. Every industrial vision project that puts a camera near a robot has to do this. Get this wrong, and nothing downstream works.

Their setup was textbook: a structured-light 3D scanner plus a precision ceramic calibration ball with 0.5-micron surface tolerance. The “gold standard” cited in peer-reviewed papers. Equipment cost starts around $30K.

Software: checked. Auto-pose-selection logic: clean. Pose distribution: well-sampled, not clustered.

But the 4×4 they got back was off by a centimeter.

I wanted to fly back. I couldn’t.

Fastest fix: get on a plane, sit next to their workstation, debug in person. The customer wouldn’t wait.

Second fastest: stare at the screen for a few minutes and realize there’s a better play. Reproduce the entire pipeline in Novi on completely different hardware.

If I could hit reasonable error with a different rig, I’d eliminate three suspects in one shot — software, calibration target, pipeline. Whatever was causing 1 cm at their site would have to live in the only remaining variable: the hardware chain itself.

This isn’t about precision. It’s bisection — using a known-good control to slice off the suspects you can rule out.

The “proper” play would have been: get budget approval for a structured-light scanner. Wait six weeks for delivery. Schedule training. Open Claude Code and prompt it furiously. Three weeks later, problem “solved.”

I wanted faster.

What I had in Novi

• Intel RealSense D435i (a few hundred dollars, desktop-grade RGBD)

• A desktop FDM 3D printer (±0.2 mm tolerance)

• A robot arm

• A laptop

Nearest “optical supplies”: a Hobby Lobby one mile from my lab. For non-US readers — Hobby Lobby is a national craft chain. It sells stuff to people doing scrapbooking and home decor.

I picked this stack on purpose. What I needed wasn’t precision matching theirs — it was hardware as different from theirs as possible. The more different my rig, the cleaner the bisection cuts.

Three physics requirements

The ceramic ball does three things, and only three things.

Physical requirement What ceramic does What $5 can do Diffuse reflection Sintered ceramic + matte polish Chalk-finish spray paint (chalk = matte = diffuse) Known geometry Factory tolerance report at 0.5 μm STL file + FDM print at ±0.2 mm (already below the camera’s pixel-resolution limit) Sharp edges Uniform spherical surface High-contrast coating (white sphere on dark ground)

Diffuse so structured light doesn’t blow out highlights and break sub-pixel edge fitting. Known geometry so you can register the detected ball center against the STL center. Sharp edges so the same 3D point shows up consistently across multiple frames.

Why 0.5 microns of tolerance? Exactly one reason: at the resolution of high-end industrial cameras, surface roughness above that starts contaminating sub-pixel edge detection. At RealSense resolution, that constraint is irrelevant — my pixels are millimeter-scale at working distance. I don’t need 0.5 μm. I need an error budget I can explain.

The boring recipe

1. OpenSCAD: a sphere shell, 3 mm wall thickness, exported to STL

2. FDM print, no supports, 0.2 mm layer height

3. 60-grit sandpaper to knock down the layer lines — two minutes, not aiming for perfect

4. One coat of Krylon Chalky Finish (matte white)

5. Cure at room temperature for 30 minutes

6. Mount on a 3D-printed jig at the robot end-effector

7. Run standard hand-eye calibration over 20 poses, depth from CREStereo — not RealSense’s onboard depth (anyone who’s done sub-mm vision work knows why)

Hardware cost: $4 spray paint + $1.50 PLA.

The numbers

• Calibration residual: 0.9 mm RMS, over 20 poses

• Algorithm clean. Fully automatic. One shot.

Now here is what that 0.9 mm number actually did — it shredded the China team’s suspect list.

I was running: a camera one resolution tier below theirs, a target whose geometric tolerance is four orders of magnitude looser, hardware costing roughly 1/100th of theirs. Same software. Same pipeline. Same pose-selection logic. 0.9 mm RMS.

If any of {software, pipeline, calibration target} actually had a bug, I would not be getting sub-millimeter. Period.

Software, target, pipeline: cleared.

So where was the 1 cm?

Process of elimination leaves one variable: the robot arm itself.

Specifically — calibration takes two inputs per pose: the camera’s measurement of where the target is, and the arm’s reported position of its own end-effector. If the arm’s report is wrong, the calibration matrix has to be wrong. Doesn’t matter what target you use.

We checked on site.

The arm’s zero point had drifted.

Not the target. Not the software. The mechanical zero of the arm. Re-zero the arm, re-run the same calibration on their gold-standard rig — error drops to 0.18 mm.

The expensive ball was always going to land on a kinematic chain that was lying to it.

Codifying it: the L2 direct RMS sentinel

After this one, I made the number itself a sentinel.

L2 direct RMS over a fixed pose set. Every time the line starts up. Every time the arm gets serviced. Every time it bumps into something. Every time the end-effector gets swapped. Run that fixed pose set first. Log the RMS.

• Stable RMS → software, target, camera-pipeline all stable

• RMS suddenly worse → suspect the arm first, software last

Most industrial-vision teams default-debug in the opposite order: software, then camera, then mechanical. That order costs weeks on every regression, not days.

A stable reference RMS lets you rule out the most expensive suspect first — and leave the cheap-but-changes-often software layer for the cases that actually demand it.

Shop-floor takeaway

1. When calibration drifts and you can’t find the bug, don’t debug on site. Reproduce the entire pipeline on a rig you fully control, with hardware as different from theirs as you can make it. That’s bisection.

2. The point of the parallel rig is not to match precision. It’s to eliminate every suspect of the form “if only the hardware were better.”

3. A fixed-pose L2 RMS will tell you the arm got bumped before any commit log will.

What you physically need: diffuse reflection, known geometry, sharp edges.

What you physically don’t need: a $30K invoice — or three weeks waiting for one.

*First Principles Manufacturing — physics, economics, and shop-floor reality from a nuclear-engineering PhD turned industrial-AI practitioner.

Subscribe now

1. The argument I thought I won

A small, no-AC meeting room next to an Apple supplier line in the Yangtze Delta. 2021.

Across the table sat an Apple MQE — Manufacturing Quality Engineer, customer side. Korean. His Mandarin was better than mine.

One-on-one. No PowerPoint. Just a stack of defect photos in front of him and an open laptop in front of me.

I talked for forty minutes

I’d been doing visual QC for a little over a year. By then I’d learned the QE vocabulary cold: false positive, overkill, miss, AOQL.

I started with the convolution math. Walked through the feature maps. Explained why this specific image had been tagged NG.

Then I dropped a level — pixel-scale texture variations, gradient differences, the way a human eye actually reads a scratch.

He nodded the whole way through. Polite to a fault.

About forty minutes in, I stopped and waited.

He paused for three seconds

He looked up at me, held a three-second silence, and said — flat, calm, in a tone I still remember:

“You don’t get it — that’s why you didn’t make me get it.”

I was angry for a beat. I’ve lectured at Shanghai Jiao Tong; I know how to teach; I know every detail in this stack — what is he even talking about?

I held it together and ran the whole thing again, slower. Same result.

I walked out of that room with one private conclusion:

This MQE doesn’t get AI. He just won’t listen.

I was 36, a year-and-change out of nuclear engineering, deep in the phase where I thought I knew everything.

2. Five years later, I realized I was the one who didn’t get it

That meeting hung around for five years.

In between, I shipped a few dozen visual-defect projects. Built three systems trying to productize the same capability.

Sat through dozens more rooms — supplier lines, customer reviews, postmortems at the equipment vendor — and met more “customers who don’t get AI.” Every single time I’d file them right next to that Korean MQE.

They don’t get AI. That’s why they ask the way they do.

Late at night, his line would replay in my head. “You don’t get it — that’s why you didn’t make me get it.” It nagged. Not because it was wrong. Because I half-suspected it wasn’t.

He wasn’t challenging my technique

He wasn’t challenging my technique. He was asking a question I hadn’t noticed I was being asked:

“What gives this thing the right to judge by the same standard I do?”

He didn’t need to understand convolutions.

What he needed to understand was this: when he looks at a part with a slightly whitened edge, his head pulls up ten years of experience, this customer’s preferences, the last batch’s source material, this week’s line conditions.

What gives a network — trained on a few thousand images — the right to call NG and assume it’s the same NG?

This isn’t a technical problem

It’s whether judgment logic can be aligned.

What he wanted from me wasn’t “explain how AI works.” It was “explain how AI aligns with me.”

I didn’t say it because I couldn’t. The 2021 me didn’t yet know alignment was a thing you could engineer.

He didn’t get the technology. Fair. I didn’t get his question. Worse.

3. How we patched the gap back then — 47 if-else rules

We had an answer for that gap. It had a respectable engineering name: post-processing.

How 47 if-else rules grow

It looked like this. The model spits out a confidence score. We bolt a rule layer on top of it:

• If the region’s grayscale mean is below X, area smaller than Y, and outside Z pixels from the edge → downgrade to OK.

• If the texture pattern matches the one the customer flagged last week → force NG.

• If the batch number starts with A8 → bump the threshold by 0.05.

• ...

Behind every rule sits a customer complaint, a stopped line, or a postmortem where the boss banged the table.

The 47 if-else rules I mentioned in the last post grew exactly this way.

Three chronic illnesses

The fix works — in the short run it does make the AI’s verdict look aligned with the customer. But it has three chronic illnesses:

1. Unmaintainable. The more rules, the tighter the coupling. A new engineer reads it once and walks away.

2. Non-portable. New customer, new product — the whole ruleset has to grow back from zero.

3. Inscrutable. You can no longer say whether the model is judging or the rules are. You’ve outsourced the alignment to 47 hand-written sentences.

We weren’t actually teaching the AI to understand the customer. We were using rules to fake understanding on the AI’s behalf.

That MQE felt this. He couldn’t put it in those words. But he knew — what you’re aligning isn’t me.

4. Five years on, the patch has a new name: “the LLM”

In 2026 the language is unrecognizable.

We don’t say “post-processing” anymore. We say priors.

We don’t say “add a rule.” We say put it in the system prompt.

We don’t say “bolt judgment logic on top.” We say use a VLM for semantic understanding.

New language, same plumbing

What’s the underlying activity? The same thing as 2021 — patching what the AI hasn’t seen in its training data.

Just that the patch material has changed. From hardcoded if-else to a model pre-trained to “know a little about everything.”

The advantages are real:

• It “understands” customer intent instead of just matching thresholds.

• It carries common sense across products without per-line rule rewrites.

• It can explain itself — at minimum, in something that reads like a human sentence.

But the substance hasn’t moved.

It’s still a patch — supplying what the AI’s training data couldn’t supply on its own: a human judgment standard.

2021 vs. 2026

The only real differences:

When Patch material Patch boundary Failure mode 2021 Post-processing rules This customer’s recent gripes One ruleset per customer, growing tangled 2026 Priors / LLMs / world knowledge Internet-scale common sense Looks universal; still needs per-customer calibration

The progress isn’t “we have LLMs now so the patch is gone.” The progress is that we finally understand the patch should be a designed part of the system, not a duct-tape strip slapped on after the fact.

This thing has been named, productized, argued about.

But there are still plenty of projects out there patching the 2021 way. Same melody, bigger model — the if-else just slid into the system prompt. The ending can be identical:

47 if-else rules become 47 system prompts. Same outcome.

5. What that MQE was actually asking — said properly

Look back at that 2021 afternoon.

The man had no AI training. His toolkit was sampling plans, SPC charts, 5-Whys, fishbone diagrams. How did he see through me in three seconds?

How he made the read

Because aligning human judgment is what he’d done his whole working life.

The entire point of a quality engineer is to take “OK / NG” — a subjective call — and turn it into something repeatable, auditable, and transferable across different eyes, different batches, different customers.

He listened to me for forty minutes and what he heard wasn’t “how AI works.” What he heard was:

“This thing can’t carry the judgment system I’ve spent ten years building.”

Three minimum bars for a stable judgment system

What he saw through wasn’t whether I understood AI. It was whether I understood what a stable judgment system looks like.

The minimum bars:

• Same part, today and tomorrow → same call.

• Different lines, same standard → comparable results.

• Something goes wrong → you can trace it to a specific decision criterion, not “the model said so.”

My 2021 version failed all three. The 47-rule version failed all three.

And today — if you’re not careful — the 47-system-prompt version still fails all three.

What that MQE refused on instinct is the exact problem the entire industrial AI industry still hasn’t solved.

He wasn’t wrong. I was. I thought he was challenging my explanation. He was challenging my approach.

6. What I’d say to that Apple MQE today

If I could sit back down in that hot little meeting room, I wouldn’t talk about convolutions. I wouldn’t talk about transformers.

I’d say:

You said I didn’t get it. You were right.

Back then I thought I did — but really, I’d just learned to dress up “humans-in-the-loop” as “AI making the call.” I couldn’t answer your real question: when I hand this thing over to you, can it judge the way you judge, write down its judgments the way your team does, pass them on to your successor the way your quality system does?

Our industry has spent the last five years slowly learning to answer that one question. We’ve gone from rules, to priors, to LLMs, to multimodal alignment — every step making “aligning human judgment” a little more systematic, a little more designable.

I still can’t put my hand on my heart and say I’ve solved it. What I have learned is that the question itself deserves to be taken seriously — and the 2021 version of me didn’t even see it as a question.

Thank you for that one sentence. It took me five years to start asking the right one.

7. Five questions to check yourself against

If you’re working on an industrial AI project in any role — customer, vendor, engineer, decision-maker — run these five:

1. Once your model gives a verdict, can you explain how it’s aligned to the customer’s standard?

2. When the customer reports a new defect type, is your first instinct to fix the data, fix the process — or to add a rule?

3. How many human-written backstops are in your system right now? Can anyone still describe how they interact?

4. If a new customer QE took over tomorrow, could they independently audit whether your system is fit for purpose within 90 days?

5. The “LLM-powered” line on your marketing page — is the system actually understanding the customer, or have you just rewritten the rules in a different language?

Three or more of these unanswered — you’re probably walking the same path 2021 me walked.

8. Next post

The next piece digs a layer deeper: “priors / world knowledge / LLMs” — those patches have to live somewhere. Which layer of the system? Maintained by whom? How do you keep them from becoming the new 47 system prompts?

The answer isn’t in the model. It’s in the architecture — there are three architecture choices industrial software should have made ten years ago. Get them wrong and AI stays stapled to the UI. Get them right and the day an agent takes over your system, you don’t have to rewrite anything.

If you’re working on this,

Subscribe now

— let’s walk this road together.

— Yuanwei, from a robotics lab in Novi, Michigan
April 28, 2026

2 a.m., on the floor of a plastics plant in southern China. I’m standing next to a visual inspection rig we deployed three months earlier. A red box flashes on the screen — false positive. The operator glances up, reaches over, taps “accept,” and says nothing.

I pull up the logs. Week 1 on the line: 94% accuracy. Month 2: customer complaints about missed defects, so an engineer added a rule. Month 3: a new defect class, another rule. Now there are 47 if-else patches wrapped around the model, and nobody on the team will touch the model itself anymore. A new hire had taken over the system the week before. His first words to me were: “I can’t tell what this thing is actually deciding anymore. Can you?”

That was the moment I realized: this system is already dead. It hasn’t crashed. It hasn’t errored out. It’s just turned into a patched-up old coat hanging on the line, reminding everyone that “we did AI here.”

This wasn’t one project. This was the same scene, playing out across dozens of systems I shipped over five years.

2. Who I am

I’m Yuanwei. PhD in nuclear engineering — radiation protection and radiation measurement, where the foundational skill is pulling a real signal out of background noise in a way that’s auditable and reproducible. In 2021 I moved from nuclear into industrial vision. The math is identical; the subject changed from reactors to production lines.

2018, suiting up before entering the Fukushima accident site.

The next five years, on factory floors in China:

• Shipped dozens of surface-defect inspection systems — phone glass, precision machined parts, injection-molded housings — together generating close to $28M USD in revenue, with customers including Microsoft, Apple, Amazon, and BYD

• Led robot deburring and automated welding programs at large manufacturers — real metal, real sparks, real arms

• Built three separate attempts at productizing the whole thing — not another one-off project, but something repeatable across customers

Along the way I picked up about 50 granted patents, co-authored two Chinese national AI standards (GB/T 42755 and GB/T 43782), and received the Wu Wenjun AI Science and Technology Award as 1st ranked contributor — one of China’s most prestigious AI prizes.

None of that is the point. The point is that none of it saved a single project from the patch trap.

This is the kind of résumé you only get by standing next to the equipment. I know the parts that never make it into the deck — the 1 a.m. customer calls, the plant manager’s death stare, the blame loop between the equipment vendor and the algorithm team, and the tired look an AI engineer gets when yet another new defect class shows up.

I didn’t learn manufacturing from papers. I learned it from standing next to the machines.

3. The real problem I saw: the patch trap

China’s manufacturing sector isn’t short on AI projects. It isn’t short on data, engineers, or opportunities. But over the last five years I kept watching the same thing happen —

every smart-looking AI project eventually slid into patching.

The loop is always the same:

1. Model goes live. 90%+ accuracy. Customer is happy.

2. A new defect shows up in the field. It gets missed. Customer calls.

3. No time to retrain. The engineer wraps an if-else rule around the edge case.

4. Next month, another new defect. Another rule.

5. Six months in, dozens of rules stacked around the model. Nobody can explain why it decides what it decides.

6. Three years in, the original team has rotated out. The new engineers inherit a black box. Nobody will touch it.

7. Eventually the line quietly returns to full manual inspection. The AI rig sits there with its status light on, ceremonially.

I call this the patch trap.

This isn’t one company’s problem. It’s structural. And the root cause isn’t that the technology is weak. It’s this:

• Customers want 100%. AI delivers 95% and a confidence interval.

• The process itself was never simplified before AI was asked to make sense of it.

• Organizationally, nobody accepts “AI can be wrong” — so every mistake has to be caught by another rule.

• Nobody wants to go back and fix the first four things — materials, tooling, process, workflow. Everyone jumps straight to step five: install AI.

The patch trap is not a technology problem. It’s an ordering problem.

(Why do we all instinctively reach for “one more rule”? A customer gave me the answer five years ago, and it took me five years to understand what he was saying. More on that in the next post.)

4. I’m not giving up — I’m trying a different path

I’m not going to sit here and complain about the industry. Complaining doesn’t ship anything.

I’m trying a different approach. The core idea is almost embarrassingly simple:

Before installing AI, make the process legible to AI.

A concrete example: one of our projects was stuck at 95% accuracy for three months. The algorithm team tried 3 architectures and over 10 hyperparameter configurations — nothing moved. The breakthrough came from outside the algorithm: we swapped the workstation lighting from 4000K cool-white to 5000K and added a polarizing filter. Accuracy jumped straight to 99.2%. This wasn’t an AI problem. It was a floor problem.

After this kind of thing happened a few times, I realized: this isn’t an algorithm problem — it’s an organizational one. Algorithm engineers are trained and measured at the model layer — but the root cause of the patch trap was never at the model layer.

So I spun off a new department from the algorithm team — Innovation Systems — combining optical, mechanical, electrical, algorithmic, and software talent under one roof. It owned its own hardware, wrote its own algorithms, designed its own process flows. Not a firefighting squad — an independent R&D force that systematically dismantled legacy problems, prototyped new systems across multiple projects, and shipped complete hardware–software stacks, process standards, and eventually several of the company’s product lines.

Among what came out of it: the Fei-Pai capture system and a software platform called Lupinus. Those are stories for another post.

That sounds like a truism. But it shifts the center of gravity of the whole project — from “how powerful is the model” to “how well do the process, the workflow, and the AI fit together as three faces of the same object.” It means going back to first principles and asking the dumb question: what is this process actually doing? Which steps are load-bearing? Which ones are historical leftovers? Which ones can we delete, merge, or reorder?

That’s where the name of this Substack comes from — First Principles Manufacturing.

I won’t try to lay the full approach out in one post. That’s going to take a year and several dozen articles. I have a long list of technical ideas to unpack, one at a time. This Substack is that window.

5. Why I’m writing this from the U.S.

I’m now based in Novi, Michigan — not far from Detroit, once the manufacturing center of the world.

A lot of people assume I came here to “learn the American way.” That’s not it.

I came here to pull myself out of the Chinese manufacturing treadmill and look at the same problems from a different reference frame.

• American manufacturing has its own knots: cost structure, talent pipeline, labor culture, hollowed-out capacity.

• Chinese manufacturing has its own knots: weak standardization, IP issues, everything-is-a-project pace, and a reluctance to build products that outlast the first customer.

• These aren’t “one is better than the other” problems. The solutions one side has developed don’t transfer to the other.

But if you spend time walking between the two, you start seeing things that neither side sees from inside:

• Why is an American factory willing to pay 10× for a piece of equipment?

• Why is a Chinese factory willing to throw 30 operators at a problem rather than install one machine?

• Where does a “process-driven” organization and a “project-driven” organization diverge at the decision level?

• How does the same AI system get used — and misused, and abandoned — inside two different cultures?

I’m not here to hand you the answers. I’m here to document the search out in the open.

6. What this Substack is and who it’s for

That’s spelled out on the About page — I won’t repeat it here.

If you work on a factory floor, in an industrial AI lab, or in a supply chain — or if you’re just curious about what’s happening behind all those cameras — this place may be for you.

7. What’s coming next

Next post: the one sentence an Apple MQE in Korea said to me five years ago — “You don’t understand it, so you can’t explain it to me.” I thought he didn’t understand AI. It took me five years to hear what he was actually asking. Most of what this industry has been doing since is a slow, stumbling answer to that one question.

After that: How All Three of My Systems Died — three attempts at productization, each killed by a different knife, each one teaching me something I couldn’t have learned any other way.

If you want to walk this with me, please:

Subscribe now

I don’t know if this new path works. But I do know that standing still is the only guaranteed failure.

— Yuanwei, writing from Novi, Michigan
April 21, 2026