cadmaster — decisions waiting on you

Updated 2026-08-02 · 10 open rulings · pin list · comparison board

Ten things are waiting on you. They are all here so you can do them in one sitting instead of me interrupting you one at a time. Six of them have been pending for days; four are contradictions the audit of 2026-08-02 turned up between documents that are both live.

How to answer: pick an option on each, then press Copy my answers at the bottom and paste the text into the chat. Your picks are saved in this browser as you go, so you can leave and come back. If none of the options is right, use the notes box — a sentence in your own words beats a forced choice.

Every one has my recommendation marked my pick with the reason. Overrule freely; the point of the sheet is that the ruling is yours and written down once.

D1blocks: customer guidelines, .ai intake

Fills or strokes on customer .ai / PDF art?

Two live documents tell customers opposite things.

  • CLAUDE.md, customer guideline 1: “Strokes only, no fills” — written to remove the “cut the fill edge or the stroke centreline?” ambiguity.
  • Pin items 2a and 14e: “fills are fine, even preferred”.

What the evidence says: the reader already accepts fills and auto-closes them. Our control file MVT-ICONtest.ai is 5 filled / 0 stroked and reads correctly. EAGLES.ai is the opposite — 5 stroke ops, zero fills, no thickness set — and also reads correctly. So both work today; what does not work is telling customers both things.

The technical argument for fills: a fill is guaranteed closed (a fill region cannot be open), and it declares which side is material, which hands us inside/outside for free. The argument against: a fill in a program that has never seen a laser can carry a stroke as well, and then there genuinely are two candidate paths.

My recommendation: b, worded as c's sentence. A fill cannot be an open path, and open paths are the single most common thing we have to fix on intake. But the rule that actually matters is one path per cut — the failure we should be warning about is a shape that carries a fill and a stroke, which is two candidate cut lines on one edge.
D2blocks: nothing today — but it produces files we cannot open

Item 14a tells customers “a PDF or SVG out of it is equally good”. We cannot read SVG at all.

vec_io raises on anything that does not begin %PDF. A modern .ai is a PDF, so .ai and PDF really are the same front-end — that half of the sentence is true. SVG is a completely different format (XML, its own path grammar) and nothing in the code touches it.

So the sentence, as printed, invites a customer to send the one vector format we cannot open, and they find out after they have sent it.

The reader itself is not large — an SVG path d string carries the same cubic Béziers we already fit, so it is a parser, not new maths. It is a queued item, not a research problem.

My recommendation: a. A published capability we do not have is worse than a missing one — the customer has already done the work by the time it fails. The reader is a day; the sentence is a minute.
D3blocks: the global open-contour FAIL, and engrave support

What marks a path as engrave rather than cut? (And the current rule is wrong.)

Pin item 8 says: “engrave runs G40, cut runs G41/G42”. Measured against your own master NC, that rule misclassifies almost the whole program: G40 appears on 90 of 91 CUT boundaries. A test keyed on comp state would call ~99% of a real cut file “engrave”. Comp state is a per-feature declaration in this shop, not a mode signal — so it can never be the marker.

The item's premise is stale as well. It says “open contour = FAIL” cannot go global until cut/engrave is known. That gate is already global and unconditional on both boards — so an engrave stroke reaching a board today produces a false FAIL, right now.

Two candidate markers, and they are not exclusive:

  • Layer name — CUT / ENGRAVE / SCORE in the DXF. Explicit, survives every export, easy to read.
  • Stroke colour — red=cut, blue=engrave, green=score. The natural channel for vector art, where there are often no layers worth the name.
My recommendation: c — plus the part that is not optional either way: comp state stops being the signal, and the open-contour FAIL becomes conditional on the path being a cut path. What I need from you and Jordan is the exact spelling of the layer names and the colour map, because I have to match whatever your customers already send rather than invent one.
D4blocks: the bridge-width numbers in item 2b

The U-T web — 0.060 stainless or 0.125 steel?

Pin item 2b judges the 23-thou web between the U and the T against 0.060″ stainless. Pin item 3b says the same file was cut on 0.125″ mild steel — and 0.125 steel is what reproduces the cut we measured against, exactly.

It matters because the web is the worked example the bridge-width rule is calibrated on: at 0.060 a 23-thou web is a marginal-but-plausible feature, at 0.125 it is under a fifth of the material thickness and a different conversation.

My recommendation: a. 0.125 steel is the one that reproduces the cut we hold, and everything downstream (slug tab table, lead length floor) is already calibrated on 1/8″ steel. But you cut it — if it really was stainless, say so and I will re-derive rather than assume.
D5blocks: the eagle vector board's pass/fail being real

One number: the eagle's real finished width, in inches.

EAGLES.ai carries a 612×792 pt artboard — that is US Letter, the Illustrator default, and it says nothing about how big the part is. The vector board for it was built at a stated width so the pipeline could be measured end to end, but every dimension on that board is therefore provisional.

With the real width the board's fidelity numbers become real numbers, and the bed-envelope and minimum-feature checks start to mean something for that file.

My recommendation: Whatever it actually is. If nobody knows, that is also an answer — it means the eagle is a scale-gate demo and not a job, and I will label it that way on the board instead of quoting numbers that look real.
D6blocks: .ai / PDF production use — the reader refuses to proceed without this

The scale convention we hand customers (pin 14b).

This is the hardest blocker on vector input and it is deliberate: vec_pipeline.read() raises ScaleUnknown rather than guess. A part at 92% is not a slightly worse part, it is scrap.

The question is only what we ask customers to do:

  • Set the document to inches and draw 1:1 at actual cut size — the size lives in the file.
  • Or state the finished dimension at upload — the size lives in a field on the form.

Note the tell that makes option 1 alone unsafe: an artboard of exactly 612×792 (Letter), 595×842 (A4) or 792×1224 (Tabloid) is near-proof nobody set the document size deliberately — a number exists but it means nothing.

My recommendation: c. Two independent sources that agree is the only state worth being comfortable in, and the cross-check costs the customer nothing they were not already doing. It also catches the specific failure neither one catches alone: a file drawn 1:1 in millimetres by someone who typed inches on the form. The upstream fix that makes this almost automatic is an Illustrator template preset to inches, 1:1, with a CUT layer — say the word and I will build it.
D7blocks: the entire estimator — pin 15e

Jordan's rate list. Ten numbers, and four old jobs that are worth more than the ten.

The estimator is arithmetic on numbers we already compute, multiplied by rates only the shop has. Until they land, anything built is a demo.

Rates: cut feed by material × thickness · pierce time by material × thickness (and whether thick stock ramps or pulses) · rapid rate · machine hourly rate (one all-in figure, or its components — say which, so gas and consumables are not counted twice).

Material: sheet cost by material × thickness with current sheet sizes · drop/remnant policy.

Labour: setup/load/unload per sheet and per job · secondary ops (tab breaking, deburr, deslag, packing) and how they are charged.

Commercial: minimum charge, rush multiplier, quantity policy · how you price today — by the hour, the inch, the part.

The one worth more than all of it: a handful of jobs already quoted and already cut, with what was charged and what it actually took. Ideal spread: one hole-heavy/lettering job, one long-cut simple job, one thick-plate job, one small-quantity job.

My recommendation: b. It is the trick that already worked once here: your hand-built master NC was worth more than every rule anyone had described, because it was the rules applied. Four real jobs also let me tell you where current quoting is off before asking anyone to trust a new number.
D8blocks: nothing — but it is the first line anyone reads on the pin list

The pin-list focus banner is out of date. Your wording.

It currently reads:

“Current focus (before anything below): INPUT vs OUTPUT = 100%. Heal fidelity — true source vs healed, measured honestly to the thou. Finish this first.”

That was true in July and it is done: all four control files pass, the healed geometry matches your programs to within half a thou on 91 of 91 boundaries. The live work is the cut path (36 crossings against your master's 4) and the preflight gates. The banner is the first thing anyone opening the list reads, so it is telling every reader the wrong thing about where we are.

My recommendation: a, because it is the item where we are measurably behind your own program and the only one where the machine can still be stopped. But this is your board and your voice; d overrules a happily.
D9blocks: verifying the pierce routine we call 91 times per program

M-code glossary — and the contents of subprogram O9011.

Every program we post calls M98 P9011 once per boundary — 91 times on the novi sign — and we have never seen what is inside 9011. We copy the call because your master NC makes it. That is faithful, and it is also the one part of our output nobody here can check: if 9011 is the pierce routine, its dwell and its ramp are the difference between a clean pierce and a blown hole, and we are sizing lead-ins around a crater whose behaviour we are taking on trust.

Also wanted, in one place: what M87 and M121 mean (they end 90 and 1 of the 91 boundaries respectively), and what M100[MSO7,0.125] is declaring — we emit all three because the master does.

My recommendation: a. Even a photo of the control screen would do. The specific thing I want to know from 9011 is whether the pierce dwells in place or ramps, because that changes the crater size the 0.150″ standoff exists to clear — and that number came from Jordan as a rule of thumb, not from a measurement of the actual crater.
D10blocks: nothing — housekeeping, but it needs your yes

The pre-history files at the top of the viewer folder.

Since build numbering came in (chunk 2), every board lives in viewer/builds/NNN-label/ with its own copies of everything. The files sitting loose at the top of viewer/ are from before that: ex2/ex3/ex5/ex6/ex7/ex9/ex11 healed DXFs and NCs from 22–24 July, a duplicate set of novi-sign_* from 31 July that build 005 already holds, and two 1.3 MB tab SVGs. Roughly 3.5 MB, nothing links to any of it, and the ex-files are outputs that any of the controls regenerates in seconds.

I do not delete things in your project without asking, even recoverable ones.

My recommendation: a. Costs nothing, keeps the board folder honest — what is at the top of viewer/ should be what the site serves — and nothing is destroyed if one of them turns out to matter.

Generated by build_decisions.py from decisions.json — do not hand-edit index.html. Your picks are stored only in this browser.