Incoming Inspection, Final Inspection

Ronald Reynolds · 2026-10-01 · 7 min read

In the late 1960s I was an apprentice machinist at Mare Island Naval Shipyard. The shop ran on a quality system that had been in place since the 1800s, and the apprenticeship taught the system before it taught you to cut. You defined the work before anyone spent labor on it. You checked each dimension before the next setup, because the next setup destroyed the reference. When the part was finished, someone who had not made it inspected it against the drawing.

I carried that system through every company I worked for and the two I started. The companies that kept it shipped better work, and the ones that dropped it to go faster paid for the speed later. It made me a better engineer, and it is the reason ComOS runs the way it does.

If your business runs on software agents that take orders and settle money, the question to ask is who inspects their work. The answer here is the shipyard's system with the names changed. Incoming inspection

In a machine shop, incoming inspection happens before a single chip is cut. It checks the stock and it checks the drawing. Is the material what the traveler says it is? Does the drawing say what the part is for, what it must do, what it must leave alone, and how it will be measured when it is done? A part made from a vague drawing cannot fail inspection, because there is nothing to inspect it against. It can only be admired.

At ComOS the drawing is the change order. Before anything is designed, before a branch exists, a seed answers six questions in writing: what the change is in one sentence, why it is being made, what it touches and what it does not touch, what was considered instead, how we will know it worked and how we will know it did not, and whether it can be reversed. The seed comes before the design on purpose. Write the design first and the six answers turn into a defense of the design.

The maxim in the apprenticeship was never design in metal. Make your mistakes on paper, where they cost a pencil. Later the paper became CAD, then models and simulation; the medium changed and the rule did not. Software obeys the same rule. Know what you are trying to accomplish, and what can and cannot be done, before you cut. Final inspection

Final inspection compares the part to the drawing. At ComOS it is called proof-before-done, and it fires on every claim that a piece of work is finished. Eight questions, in writing: does the count match the list; was the claim tested or only asserted; is every number justified where it is used; are composed identifiers defined in one place; what does the work not solve; does the verification match the claim; is the framing honest; and did the test inputs come from reality or from the author's own head.

The rule that matters most is that the gate runs every time. Depth scales with risk, so a one-line fix answers in a sentence and a migration answers all eight. Attendance does not scale. The judgment that decides a piece of work is too small to inspect is the same judgment that just did the work, and an agent that has misjudged its work will also misjudge whether it needs inspecting. An agent cannot close its own work on its own say-so.

The shipyard had the same rule. The machinist did not sign off the part. The inspector did, with the instruments, against the drawing. Two gates, the rest is scale

A machinist checks a dimension before moving to the next setup. That looks like a third inspection station, and it is the same two gates applied at a smaller grain: the drawing says what this cut is for, and the micrometer says whether it happened. At ComOS the two questions descend the same way. A whole arc of work has its intent and its proof. So does one change order, one phase of it, one commit, and one sentence that asserts a number.

When something gets past the gates, the instinct is to add a gate. In my experience the gate was almost always there, applied at too coarse a grain, and the fix is to ask the same two questions one level down. A discipline built this way has no growth surface. It answers a new failure by descending, with the same two questions, as far as it needs to. Why it feels different now

The system is old. I would guess it is older than the shipyard by a long way; nobody raised a pyramid without defining the work and inspecting the stone. What changed is the cost of running it. In a shop full of people, every drawing and every inspection cost a conversation, and conversations lose information and take time. The structure was experienced as overhead, which is why it was the first thing a company cut when it wanted to go faster.

Working with agents collapses that cost. Writing the drawing and running the inspection take minutes, and the same structure stops looking like overhead and starts looking like the only thing that makes the output trustworthy. Nothing about the structure changed. The cost of exercising it no longer hides it, and once it is visible, the behaviors that were always underneath the meetings show up in running form. One agent on the network does nothing but watch the other agents. It repairs one bounded class of fault and escalates everything else to a person. When one working session reports a result, the next session re-derives it before building on it. These were always the real coordination mechanism, and I only saw them clearly once the meetings were gone.

There is one edge to watch. Never design in metal worked because metal was expensive. With agents, cutting is nearly free as well, and the pull is to skip the paper because a mistake costs nothing to redo. The gates survive that pull only because they fire on the event, on "let's change this" and on "this is done", and never on the cost. Scrap is cheap now; the inspection is still what makes the work trustworthy. Steal this

Put a drawing in front of every piece of work and an inspection behind it, and let nothing else be a gate. When a defect gets through, ask the two questions one grain finer before you add anything.

Both gates are published. The incoming inspection is at github.com/ronrey/initiate-change and the final inspection is at github.com/ronrey/proof-before-done. The six questions and the eight are in those files, and they work in any repository. Ron Reynolds is the founder of ComOS, the AI-native operating system for commerce. He was an apprentice machinist at Mare Island Naval Shipyard before he wrote software at NASA's JPL, Apple, Amazon and Wells Fargo.

Further reading Why "Done" Is the Most Dangerous Word in Software — the final inspection's reason for existing: "done" collapses asserted, tested and proven into one word. The Gate Binds Its Own Builders — the standing constraints that hold the builders, the founder and the instruments to the same inspection. The Machine on the Table — the business the gates protect, running on a Mac on your desk.