2026-03-31
You generate a fixture plate from a STEP file. The boolean subtraction runs, the pocket gets cut, the file exports. But how do you know the output is dimensionally correct? A bad boolean can silently produce a pocket twice as wide as it should be. A degenerate solid can export with zero volume. A fillet that failed mid-operation can leave the plate 5 mm shorter than specified.
You would find out when the machined fixture does not hold the part. That is too late.
On a shop floor, a coordinate measuring machine settles the question. Put the part on the granite table, probe a grid of points, compare to the drawing. Dimensions within tolerance: pass. Outside tolerance: reject. The CMM does not care if the part looks correct. It measures.
The geometric oracle does the same thing to generated CAD. Before the file leaves the server, the oracle imports the STEP output, measures its bounding box and volume, and compares against declared ranges. No physical probes, no granite table — just the geometry kernel reading its own output and checking whether the numbers make sense.
The key word is declared. The expected dimensions are not learned from historical data. They are stated explicitly by the tooling configuration, the same way a machinist reads tolerances from a drawing. The oracle is not making a judgment call. It is comparing a measurement to a specification.
Every tooling configuration publishes its expected dimensional ranges before generation
runs. The format is a dictionary of (min, max) tuples, one per measurement:
| Measurement | Units | Role |
|---|---|---|
bbox_x |
mm | Output width |
bbox_y |
mm | Output depth |
bbox_z |
mm | Output height |
volume |
mm³ | Material volume of the solid |
num_faces |
— | Topology count (advisory) |
A concrete example: a fixture plate generated for a 100 mm wide part. The plate is
always wider than the part — it needs room for the bolt pattern and edge stock. So the
configuration declares bbox_x: (180, 220). If the output measures 195.3 mm
wide, that is within range. If it measures 412.7 mm, the boolean produced garbage and
the file gets rejected.
The ranges are not tight tolerances. They are sanity bounds. A fixture plate is not going to be 12 mm wide when the part is 100 mm. It is not going to have a volume of 47 mm³ when it should be a 10 mm thick aluminum slab. The oracle catches the catastrophic failures — the ones where the geometry is structurally wrong, not slightly off-nominal.
After generation, the oracle imports the output STEP file and queries the geometry kernel directly:
This is pure measurement. The oracle does not interpret the geometry, does not classify features, does not estimate tolerances. It reads numbers from the kernel and compares them to the declared specification. Same thing a CMM does with a point cloud and a CAD model.
The oracle distinguishes two severity levels, and the distinction matters.
Failures are dimensional: bounding box or volume outside the declared range. A failure means the geometry is wrong. The file is rejected. You do not see it.
Warnings are topological: face count, edge count, or vertex count outside the declared range. A warning means the geometry might look different than expected — maybe a fillet produced more faces than usual, maybe a boolean split an edge. But the physical dimensions are correct. The file passes.
Why the split? Because dimensions are physical. A bounding box that is 50 mm too wide will produce a fixture plate that does not fit in the vise. That is a real problem. A face count that is 12 higher than expected usually means the kernel decided to split a cylindrical face at a seam line. That changes nothing about whether the part seats correctly.
Dimensions alone do not catch everything. A solid can have the right bounding box and volume but still be broken at the BRep level — open edges where faces should be joined, degenerate faces with zero area, edges shared by the wrong number of faces.
The oracle runs OpenCASCADE's BRepCheck_Analyzer on every output solid. This
checks each face, edge, and vertex for geometric and topological consistency. It also runs
ShapeAnalysis_Shell to detect free edges (a face boundary that is not shared
with any adjacent face) and bad edges (shared by more than two faces, which is physically
impossible for a manifold solid).
Finally, it checks for degenerate geometry: faces so small they are essentially points (spot faces), and faces so narrow they are essentially edges (strip faces). These do not necessarily make the solid invalid, but they cause problems downstream — CAM software may generate erratic toolpaths around degenerate faces, and mesh export can produce sliver triangles.
In shop terms: the dimensional check tells you the part is the right size. The BRep check tells you the surfaces are closed and the edges are clean. Like inspecting both the dimensions and the surface finish before you ship.
If you were generating one fixture plate at your desk, you would open it in your CAD viewer, rotate it, check that the pocket looks reasonable, and move on. The oracle would be overkill.
OPJAW generates workholding on a server. The pipeline runs headless — no screen, no viewer, no human looking at the output before it ships. A customer uploads a STEP file, the server generates tooling, and the result goes into a download. If the pocket boolean failed silently and produced a solid with the pocket on the wrong face, nothing in that pipeline would catch it without the oracle.
The oracle is the inspector on the line. It checks every output, every time, and it does not skip parts because it is Friday afternoon.
We validate the oracle (and everything upstream of it) against 20 off-the-shelf industrial components — pillow blocks, gears, ball valves, star knobs, pipe crosses, heat sinks. They cover prismatic, rotational, organic, tubular, and mixed geometries. They are not selected to make the system look good. They are selected to break it.
Every code change runs the full pipeline against all 20 parts, across every tooling strategy. The oracle checks every output. If a code change causes a fixture plate that used to measure 200 mm wide to suddenly measure 400 mm, the oracle flags it as a regression and the commit is blocked. Not just logged. Blocked.
Parts that a given strategy cannot handle — a pipe cross has no flat seating face for a fixture plate — are expected to be rejected cleanly. An incompatibility is a correct result. A dimension outside its declared range is not.
Related articles: