You give it a 3D model of a metal part. It works out how to carve that part out of a solid block, and writes the instructions the milling machine reads. This page explains the machinery behind that, in order, without assuming you know either CAD or code.

Imagine handing someone a photograph of a finished sculpture and a rectangular block of aluminium, and asking them to write down every cut needed to get from one to the other — which cutter, in what order, from which side, how deep. That is the whole job.

Anvil does it automatically. The reason that takes ~53,000 lines is that each of those words — which, what order, which side, how deep — is a separate hard problem.

In the order material actually moves

Everything else hangs off this sequence. Each stage hands its output to the next, and the numbering is real — you cannot plan a cut before you know what you are cutting.

1. 1

   Read the shape

   A CAD file is just a bag of surfaces — it says "there is a cylinder here" but not "that is a bolt hole". This stage looks at every face and decides what it is: a pocket, a hole, a boss, a chamfer. Everything downstream depends on that translation being right.

   feature_extractor.py 3,478 rule_engine_yaml.py 1,025 labeler/rules.yaml 2,812
2. 2

   Work out how the features relate

   A hole inside a pocket must be drilled after the pocket is opened. A raised island has to survive the clearing pass around it. This stage builds the map of what depends on what, and decides how many times the part must be turned over in the vice — each turn is a "setup", and each one costs real time on a real machine.

   constraint_graph.py 1,463 setup_engine.py 545 workholding.py 772
3. 3

   Plan the operations

   The brain. For each feature it picks the cutting tool, the speeds, how deep each pass goes, how far sideways the tool steps between passes, and what order everything happens in. This is where machining knowledge lives, and it is the largest single file in the project by a wide margin.

   strategy_solver.py 6,039 machining_rules.py 687
4. 4

   Draw the cutter path

   The plan says "rough this pocket with a 10 mm cutter". This stage turns that into the actual line the cutter tip travels through space — thousands of coordinates, spiralling inward, stepping down, ramping in at an angle so the tool never drops straight into solid metal.

   toolpath_generator.py 4,606 polygon_utils.py 1,166
5. 5

   Check the result

   Before anything reaches a machine, the path is simulated: material is subtracted from a virtual block and the result compared against the original model. Anything left uncut, or cut away that shouldn't be, is reported and attributed to the feature responsible. Separately, every move is graded against the machining rulebook.

   machining_grader.py 1,632 verifier.py 958 manifold_diff.py 648 deviation_attribution.py
6. 6

   Write the machine's instructions

   Finally the path becomes G-code — the plain-text language every CNC machine speaks, a list of coordinates and feed rates. If any check in stage 5 failed hard, nothing is written and the job reports why instead.

   post_processor.py 686

The difference that mattered

Anvil carries a distilled body of machining knowledge — feeds and speeds, how deep a cut may be, when to switch cutting direction, how small a tool may follow a bigger one. It lives in MACHINING_KNOWLEDGE.md, and every number in the code cites the line it came from.

Until recently that knowledge only ever ran in one direction: as an inspector, grading a finished toolpath. The planner that produced the toolpath had never read it. Both had opinions about how deep a cut should be; they agreed only where somebody had typed the same number into both places by hand.

Each planning rule now names the function that must obey it, and scripts/machining_rule_consumption_audit.py fails the build if that function stops reading it, gets renamed, or is never actually called. A cited threshold has to be load-bearing, or it quietly decays into a comment — which is exactly what had happened.

The learning loop never touches your upload

There is a language model in this project, and it is kept out of the path your file travels. When you upload a part the pipeline is rule-based and deterministic: it either produces G-code, or it stops and tells you which piece of geometry defeated it — in seconds to minutes, not a quarter of an hour.

The model works on the other side of the wall, on its own schedule, against the pile of parts that have previously failed. What it proposes arrives as a code change for a human to review. The algorithm improves in discrete, audited steps, and nobody's upload pays for that improvement.

Three machines, one request

The browser never talks to the compute server directly — a secure page cannot load an insecure one, so requests are relayed. Merging an approved change redeploys the server automatically.

What is alive, and what is not

The structure holds up better than its size suggests: 80 of 96 modules are reachable from a real request. This is not a scattered collection of disconnected pieces. But nine modules — about 2,700 lines — are imported by nothing at all, including the tests.

The four automated gates — feature coverage, operation-geometry contract, recognizer signal, and rulebook consumption — each exist because something once passed every test while being quietly wrong. They are worth reading as a list of the mistakes this project has already made.