Kernel robustness on real-world CAD files

Any kernel looks good on its own primitives. NativeCAD is measured on other people's geometry: SolidWorks parts, STEP and Parasolid files from real vendors, put through the same operator battery every sweep. Imported parts mesh, measure and round-trip through STEP at or near 100%. Since September, blends on real parts have gone from rare to routine, and every boolean now builds more often than it did.

IGES, since 2026-09-02

IGES has its own scoreboard. IGES files arrive as loose surfaces that the importer stitches into solids, so they are a different question from native solid formats and are measured separately. Unions and subtracts on IGES parts have gained since September. Intersect results are now checked against an independent volume estimate, and a body that fails that check is scored as a miss. That stricter check is why the intersect bar is shorter than in September.

Design loops, since 2026-09-29

The corpus above imports other people's files and runs whole-body operators on them. It never asks for what a designer reaches for next: move this wall, draft that face, round only those edges, shell the block. Design loops do. An agent builds a part, asks a verdict tool what is wrong with it, and applies the fix the verdict names, one call at a time. Every call it makes on a part it built itself is scored here, and every refusal is kept as a minimal repro with a fingerprint, so one defect is filed once instead of once per run. These are our own parts, so their rates carry no jitter. The set is small and one refusal moves a row by tens of points: read a row as "builds" or "refuses", not as a trend. The first sweep is the baseline.

Blends, broken down

The every convex edge at once rows are deliberately the hardest question in the family: one radius on every convex edge of a real machined part, and a single refused edge fails the body. Real parts are full of edges nobody would fillet, such as the tangent seams where a corner-round already meets its wall, so that figure says little about what the blend engine can do. The indented rows ask what a designer asks: round this edge, round this chain, round the inside corner, vary the radius along the way. Those are the rates this sprint is moving. On geometry the engine can reach, this is what it delivers:

Method

Each corpus file is imported through the product import path. Files that produce at least one solid go through the battery: tessellate, mass properties, boolean union / intersect / subtract against an overlapping box tool, fillet and chamfer on every convex edge plus the single-edge, chain, concave and variable-radius cases, shell, and a STEP write/read round-trip. Every operator runs on a fresh import, so one operator's document mutation never contaminates the next measurement. A per-file time limit turns a hang into a recorded timeout, and whatever finished before it is kept.

The boolean rows also cross-check the volume identity vol(A∪B)+vol(A∩B) = vol(A)+vol(B) whenever union and intersect both build; the share of checked parts passing it is reported above. Every boolean and blend result is also checked for validity and against a volume bound. A body that fails is counted as a wrong answer, never as a success. A silent wrong answer is the most serious fault a kernel can have, and each one becomes top-priority work the same day.

Why publish this

Robustness is only real when it is measured on files we did not author. The same sweep that renders this page files the tickets for the next round of kernel work, and the page is regenerated when that work lands, so what you see here is the kernel you would install today.

Tolerance reclassification, since 2026-09-05

CADSF-1159 gave every imported solid a per-entity tolerance profile (Topology.toleranceSummary()) instead of one global epsilon for the whole model. This re-sweeps the same pinned 150-file subset the CADSF-1089 retro used (corpus/robustness_subset.json) and asks the question that opened up: of the files the battery calls not_watertight, how many are actually closed once each seam gets its own declared or derived tolerance instead of being held to one model-wide epsilon — and how wide is the tolerance that closes them? A file lands in the new tolerant_ok class when Topology.validate() reports the shell closed (valid: true) but its tolerance.countAboveEps is greater than zero — at least one seam only meets because its own tolerance is wider than this model's eps. Everything else keeps its old class: watertight (closed with no seam needing more than eps) or not_watertight (still open or non-manifold even with full per-entity widening).

Recovered by the fallback ladder

When an operator refuses, the kernel retries it down an ordered ladder of fallback strategies (a reordered edge chain, a split chain, a reduced radius, a swapped boolean operand, a thickened shell) before giving up. Each bar splits the same battery run into the share that passes with no ladder at all, the share the default ladder recovers, and the share that still refuses. The default ladder never uses a rung that degrades the geometry.