4g. machine.json and the material table — the numbers, and where each came from

kerfmaster pin list · Big capabilities

recordclosed d19States what the code does today. Auditable against the code — this is the only type that can go stale.

Content last changed 2026-08-13 — computed from the item itself, not typed.

This contract describes the code as it runs today.

takes —

makes machine-profilematerial-table

fails if A number typed into Python that belongs to a laser or a material; a lookup that answers from a neighbouring thickness; a value with no source beside it.

Contract last changed 2026-08-06 — computed, not typed. Dated separately from the text above, so neither date can speak for the other.

2 open questions block this pin

Q7 What are the shop codes for copper, aluminium and stainless? Every file we hold says MSO7.
Jordan — materials.json has four rows and all four are MSO7.
Q13 Do you expect kerf to open up with thickness? Every program we hold is D7 / .007 from 0.060 through 0.990.
Jordan — Four material rows, one kerf value, recorded as a measurement because that is what the programs say.

⚠ Known defects

This item's subject has a known defect in the code. Source: cadmaster/defects.json → cadmaster/KNOWN_DEFECTS.md, not this page — the text below is generated from the register so the two can never disagree.

D19 — The holes report called every consumer of a cross-cutting artifact 'backwards' (CLOSED)
pipeline_model()'s rank() read STAGE_ORDER straight, which gives the cross-cutting stage `all` position 10 -- after post and report. The comment two lines below said 'all is not a position in the line, so it never counts'. The code did not do that.
Cost today: One build. The false grade existed only between adding pin 4g and fixing this, and no page carrying it was published.
Verified: 2026-08-06. rank() now returns 99 for `all` and for the unassigned stage. Fixed in the commit that exposed it.

Until this was built the numbers lived in two places at once: in prose in CLAUDE.md, and copied into whichever Python module needed one. The drop-through 0.75 was written out five times — emit, bigpiece, tipping, cutpath_dxf, build_vec_board. The bed 80 × 160 twice. Nothing was wrong while every copy agreed. The defect is that moving a job to a different laser would have updated some copies and not others, and the wrong one is the one nobody looks at.

What exists

machine.json — properties of the LASER: bed 80 × 160, drop-through 0.75, start clock 12. Plus the slat description, recorded as description and explicitly flagged as never an input to a calculation (Jordan, 2026-07-31).
materials.json — properties of the STEEL, keyed MSO7,0.125: kerf, the slug-tab bands, and the lead/standoff rules. Four rows today, 0.060 / 0.125 / 0.250 / 0.990, every one read out of a program the shop wrote.
tables.py — the only way to read either. Resolution order repo default → per laser → per location → per job; misses raise rather than guess.

Three things the corpus settled on the way

The G52 margin is not a material property. CLAUDE.md assumed it was. The corpus disproves it: 65733 and 65734 are both MSO7,0.125 and carry G52X.35Y.2 and G52X.2Y.2. Same material, different shift. It is per-job with a default of 0.2/0.2, and materials.json says so where it keeps it. (MSO7,0.990 carries G52X.2Y.95 — which is where the long-standing Y.95 in CLAUDE.md came from.)
Kerf does not open up with thickness — in anything we hold. Every program in the corpus is D7 / .007, from 0.060 to 0.990. That is a measurement, recorded as one. If the shop expects kerf to grow with thickness then one of the two is wrong, and it is worth asking Jordan which.
Provenance travels with the number. Each value has a source beside it: measured (read out of a file or a cut we hold), decided (a person ruled it), assumed (nobody has confirmed it). tables.unsourced() lists any value that carries none — a number nobody can account for is the one that turns out to be a guess. This covers the numbers in these two files only; the rest of the project is not yet marked.

Two defects fell out of the move and were fixed in the same commit: D17, the vector front-end's bed check reading a key no profile has ever had, and D18, a post declaring 1/4" steel in its header while piercing with a lead sized for 1/8".

Control: the two production posts, which state their material explicitly, are byte-identical before and after across two files, as are the healed geometry posts and the slug reports. The only output that moved is the one carrying D18, and it moved on 19 rapid-to-pierce positions and no cutting move.

2026-08-12 — first BORROWED row: MSO7,0.075 (14 gauge, 0.0747 in). Aristide, commissioning the TL-1016-61 post: “I know we don't have that in the table yet but you can use the same settings as for 1/8 inch steel.” Kerf 0.007 and the slug-tab bands are copied from MSO7,0.125, every field marked decided (his ruling), not measured. Lead/standoff resolve to the 0.150 floor by the existing rule. Borrowing DOWN in thickness rounds the safe way for retention (lighter slug, same tab). The key string itself is marked assumed — we hold no 14-ga NC, so how the shop writes it in a header is a guess to be corrected from their G-code for this very job. The row also proves the table's shape: a new material was a row someone typed, no Python changed.

Same day, closed: their G-code for this job (33199.NC) arrived and settles the key — the shop writes 14 ga as MSO7,0.080, and their header carries the same #2007=.007(D07) kerf as 1/8, independently confirming the borrow. Row renamed, key provenance now measured. Their post also shows a flat 0.030 uncut tab on all 48 part OUTERS (nest-stage part tabs, item 3a — first shop number for the width table) while leaving the three interior slugs over drop-through untabbed, and one Ø0.51 circle inexplicably tabbed — both raised with Jordan.

2026-08-13, Jordan (ruling) — arc-center ceiling. “Anytime we have an arc center greater than 9999" make it a straight line (G1). However, this 9999" value we should pull from a table that we can change down the road. So make it a variable, but set it to 9999" for now.” Lives as arc_center_max in machine.json (a control-format limit, so a MACHINE number), read via tables.arc_center_max(); applied in both G-code writers, straightened moves counted in stats["arcs_straightened"]. Measured before wiring: no delivered program exceeds it (worst |I/J| 9533, TL-1016-81 sheet 1), so the rule guards the future rather than recalling anything shipped.

Same day, refined by Jordan’s LARGE ARCS EXAMPLE.dxf. Two parts share one ~14,280 in radius arc: a 1 in part whose span sags 0.0000088 in (a single line, no issue) and a 119.5 in part whose span sags 0.125 in — where the original “make it a straight line” reading would cut a visible flat. The gate is therefore the SAG OVER THE SPAN WE CUT, never the radius alone. Over the ceiling both G-code writers now emit the fewest equal chords whose sag stays under chord_sag_max (machine.json, 0.002 in — derived from Jordan’s criteria “not too small so that it causes sloppy CAD, but not so big that it’ll be visible on the finished part (i.e. visible corners)”, then ratified by Aristide same day: “make this the new rule”; Jordan may still swap in his own number, one field in the table); a single G1 is just the n = 1 case. On his example: 8 chords of ~15 in on the 10 ft part (worst deviation 0.00195 in, joint angles 0.06°), one line on the 1 in part. Chorded moves are counted per boundary in stats["arcs_chorded"]; nc_audit’s 0.005 in on-source-geometry gate would have flagged the old single-G1 flat and passes the chords (verified, build #26, 0 anomalies). No delivered program ever crossed the ceiling, so nothing shipped moves.