Our QA agent reported zero interference. The part had a hole in it.

I build 3D parts with an agent pipeline. A design agent writes parametric build123d Python, a QA agent runs a diagnostics engine against it, and nothing ships until QA returns PASS.

One of the numbers QA reports is interference: the volume where two solids occupy the same space. Overlapping parts cannot be assembled, so interference has to be zero.

It was zero. The part had a hole in it.

What the check actually computes

An interference check is a boolean intersection. Take solid A, take solid B, compute the volume of the region belonging to both. If that volume is zero, nothing collides.

Read that again with an adversarial eye. The check asks is there material in two places at once. It has no opinion whatsoever about material that is in no places.

So when the design agent generated a body whose wall never got made — a cut that ran further than intended, a feature that silently failed to fuse — the intersection against that missing wall was empty. Not "empty because the parts clear each other." Empty because one of the operands had nothing in it.

The gate returned 0. Zero is the number you want. The part was broken.

Why this is not a bug in the check

It would be comfortable to call this a defect in the interference routine and patch it. It isn't one. The routine computed exactly the right answer to exactly the question it was asked.

The defect was mine, in what I chose to assert. I had written a gate that could detect the presence of a problem and then treated a clean result as evidence of the absence of problems. Those are different claims, and only one of them was being tested.

This generalises past CAD, which is why I am writing it down. Most verification people bolt onto an AI system is presence-detection:

• Did the output contain a forbidden string?
• Did the schema validation throw?
• Did any assertion fail?
• Did the model refuse?

Every one of those passes trivially on an empty result. A pipeline that produced nothing at all sails through a suite made entirely of "did anything go wrong" checks, because nothing went wrong. Nothing went anything.

The fix: assert the material, not the absence of collisions

The repair was to stop interrogating the CAD model and start measuring the artifact it exports.

The pipeline now samples the exported mesh with an occupancy grid. Pick the volume where material is required — the wall between the board cavity and the outside, the boss a screw threads into, the floor under the PCB — and sample points inside it. Every sample has to land inside solid material. A point that lands in air is a FAIL with coordinates attached.

That inverts the question from is anything overlapping to is everything present. The second question cannot be satisfied by an empty output.

A related correction landed at the same time. The keep-out volume around a component is a brick, not the component's own shape. If you model the keep-out as the part's exact geometry, you get a check that permits an enclosure wall to nestle into every concavity of a connector — geometrically clear, physically impossible to assemble, because the connector has to travel through that space to get where it ends up. The keep-out has to include the room the part needs on the way in.

And a second pair of eyes that has not read the file

The occupancy grid closed this particular hole. It does not close the general one: a gate only tests what its author thought to test, and I am the author of both the gate and the thing being gated.

So after QA returns PASS, the pipeline spawns an independent mechanical reviewer that gets the renders and the printed-part list and one question — would this work mechanically? It does not see the QA output, the design history, or how many rounds it took. It reasons from the pictures.

It runs after QA passes, never instead of it. They catch different classes of thing. QA catches what is measurable and known in advance. The reviewer catches the assembly that is geometrically valid and physically absurd — the bracket that holds nothing, the fastener you could never reach with a driver.

That is worth its own post, and it has one.

The part worth stealing

If you are putting a verification layer on an AI system, the useful exercise is not listing what could go wrong. It is asking, for every check you have:

Would this pass if the output were empty?

For a surprising number of checks, the honest answer is yes. Those are not tests. They are the absence of a complaint, and I shipped a part with a hole in it because I could not tell the difference.

---

This is the same gate we build into client work: written pass/fail criteria agreed before any code, and the engine that runs them. How that works.