kerfmaster — open questions

Q1 For .ai/PDF art that carries no real-world size: do we tell customers to set the document to inches and draw 1:1 at actual cut size, require a finished dimension stated at upload, or require both and cross-check them?

Theirs because It is a customer-facing convention, and no measurement can settle it. Both .ai files we hold carry a 612x792 pt Letter artboard -- the application default, which tells us nothing about how big the part should be.

Waits on the answer

• scale-gate — The gate is built and the convention behind it is not chosen. The pin exists to hold this question.
• vector-frontend — Built, wired and measured end to end, and still cannot send a job to the floor.
• uploader — The required-field list on the upload form cannot be settled until we know whether a stated dimension is mandatory.
• true-size — Consumed by a record pin, produced by none. One of the two unrecorded holes in the pipeline view.
• scale stage — The whole stage is one decision wide.
• eagles — Runs only because we typed a width and marked it assumed.

blocked vec_pipeline.read() raises ScaleUnknown unless exactly one of width_in or scale is supplied (vec_pipeline.py:128). Every .ai in the corpus runs on a size a human typed. A wrong answer here does not make a slightly worse part, it makes scrap.

We propose Do both and cross-check: ship the Illustrator template AND require a stated finished dimension, then stop and ask whenever stated divided by measured is not 1.000. That is already the recommendation written on pin 14b; it needs a yes, not a design.

Asked: 2026-08-01, Aristide, during the vector front-end work: "we should check for an indicator for a scaling. And if it's missing, we would need to flag it and ask it."

Q2 What does EAGLES.ai actually cut at? Our 12 inch width is our own guess.

Theirs because Only the person who ordered it knows. It is the concrete instance of Q1, which is why it is listed separately: Q1 is the policy, this is one file waiting.

Waits on the answer

• eagles — width_in 12.0 is recorded as an assumption; every dimension the corpus records for this file is scaled by it.
• cadmaster/viewer/eagle — The published eagle board states sizes derived from the guess.

assumed, and shipping 12 inches, chosen by us. Everything on the eagle board -- extents, bed check, feature sizes -- is that guess multiplied out. The numbers are internally consistent and may all be wrong by one factor.

Asked: 2026-08-01, when the file was first read -- it has no stated size.

Q3 How does a file tell us a path is engrave/score rather than cut -- layer name, stroke colour, or both?

Theirs because It is a convention we impose on customers, and Jordan has explicitly told us to hold no rule until an engraving file arrives: "We simply have not ever given you the engraving instructions on any of the files we've been testing with. You should have no rule at this point."

Waits on the answer

• cut-engrave — The pin is the question.
• qc1 — Its gate FAILs on open contours. That cannot go global while an engrave stroke may legitimately be open.
• intake stage — Nothing classifies a path at read time.

no rule held There is no engrave branch anywhere in the pipeline -- checked. Two facts are settled and cost nothing to hold: engraving carries no tipping weight, and all engraving runs before any cuts. What is missing is only the marking convention, and no file we hold contains engraving to learn it from.

Asked: Standing since the cut-vs-engrave pin was written; narrowed by Jordan 2026-08-04.

Q4 "Strokes only, no fills" -- is that a hard rule we reject a file on, or a preference we heal around when a fill turns up?

Theirs because It decides whether a paying customer's file is refused. That is a commercial call, not a geometric one.

Waits on the answer

• ai-vector — Carries the guideline as a guideline with no enforcement behind it.
• preflight-gate — Three outcomes, and a fill has not been assigned to one of them.
• intake stage — vec_io counts filled paths and passes them straight through.

nothing built on it vec_io records a fill count and lets the file through (vec_io.py:293). A fill also implicitly closes its subpaths, so a filled path already reads differently from a stroked one -- but nothing warns, blocks or asks. EAGLES.ai has zero fills, so nothing we have run has exercised it.

Asked: Written into the customer upload guidelines 2026-08-01; never ruled on.

Q5 We tell customers an SVG out of Illustrator is "equally good" and we have no SVG reader. Build one, or amend what we tell them?

Theirs because One of the two statements is his ruling (14a, how to deliver files to us). Which one moves is his call.

Waits on the answer

• delivery-rules — The ruling names SVG as an accepted delivery format.
• ai-vector — The record says plainly: "SVG is still unwritten."

two records disagree svg_io.py exists but is a flattening path parser (flat=48) -- exactly the polylining we exist to undo -- and as of 2026-08-06 NOTHING imports it. Its one caller, mvt_prep, now reads the customer's .ai through our own PDF reader instead. So if a customer took us at our word today and sent an SVG, nothing would read it, and the file that shares its name is dead code.

We propose The reader is genuinely small -- SVG carries the same path ops plus a native A arc we would preserve like a DXF bulge -- so building it is the cheaper fix. But it is scope, and scope is not mine to add.

Asked: 2026-08-06, reading the delivery ruling against the vector record.

Q6 Which material and thickness is the reference case -- 0.060 stainless or 0.125 mild steel?

Theirs because It is a decision about which of two real test cuts we treat as the base row, and both came from the shop.

Waits on the answer

• slug-tab-rules — The slug-tab bands are validated on 0.125 steel only, and say so.
• bridges — Jordan's starting bridge widths were given for .060 stainless.
• D4 — The DXF board contradicts itself about material thickness -- this question is upstream of the fix.
• build_board.py:THICK — 0.060 with no stated source, on a board whose production post is MSO7,0.125.

two records disagree The DXF board reviews bridges at 0.060 and posts G-code at 0.125 on the same page. Registered as D4 and deliberately unfixed, because choosing a number would be answering this question ourselves.

Asked: Standing. The two bodies of shop knowledge we hold are on different materials.

Q8 May a material row ever match a RANGE of thicknesses rather than one exact value?

Theirs because It is the question of whether shop numbers interpolate. Only the floor knows whether 0.135 stock cuts like 0.125.

Waits on the answer

• table-format — Second of the three open questions on the pin.
• material-table — Exact match today; a thickness we have never tested raises rather than guessing.

no rule held No bands. Exact match only. The lead-length rule already scales with thickness because Jordan stated it as a rule; slug-tab widths do not, and there is no evidence yet that they should. Inventing a tab width for an untested thickness is the exact failure the table exists to stop.

Asked: 2026-08-04, when the material table was built.

Q9 Can a per-location override be locked, so a per-job value cannot silently overrule it?

Theirs because It is a policy about who may overrule whom, not a mechanism. The mechanism resolves already.

Waits on the answer

• table-format — Third of the three open questions on the pin.
• operator-picks — Every value is overridable; nothing yet refuses to be.

nothing built on it Repo default, then per laser, then per location, then per job -- later wins, deep-merged per key. It resolves; it does not yet refuse.

Asked: 2026-08-04, when the override order was built.

Q16 Snap gaps at or under 0.5 thou, flag from there to 60 thou -- are those the right numbers, and should the snap stay silent?

Theirs because It decides what we silently change in a customer's drawing. That is not ours to set by default.

Waits on the answer

• autoclose — The pin is the question.
• qc2 — Reporting what was stitched or closed is QC step 2's job, and it is not built.
• heal stage — Both thresholds run unconditionally on every heal.

assumed, and shipping dxf_io.stitch_open_polylines joins fragment ends within 1.0e-4 in; heal.close_micro_gaps bridges up to EPS_DROP = 5.0e-4 in (heal.py:456); qc.GAP_FLAG = 0.060 (qc.py:26) is the flag side. All three run on every file and nothing tells the operator how many fragments were stitched or how many gaps were closed.

Asked: Standing on the auto-close pin; the numbers were chosen in code, never ruled on.

Q18 The pin list's focus banner still reads "INPUT vs OUTPUT = 100%. Heal fidelity ... Finish this first." What should it say now?

Theirs because It is the one line at the top of the record that says what we are doing. His to write.

Waits on the answer

• spec-mission — The banner sits above every view of the list and contradicts the definition-phase statement below it.
• cadmaster/pinlist/pins.json — focus, at the top of the file.

two records disagree The banner tells a reader heal fidelity is the current focus. The phase statement in CLAUDE.md says we are in definition and analysis. Both are on the same page and a new reader cannot tell which is live.

Asked: Raised 2026-08-02 in the audit; still the live wording.

Q19 Which files in the viewer root are still wanted and which are debris?

Theirs because It is a delete on published output. Nothing here is worth guessing about.

Waits on the answer

• history-board — Numbered builds live under viewer/builds/; roughly two dozen loose files predate that and nothing links to most of them.
• cadmaster/viewer — The published site root.

nothing built on it Costs nothing but clarity. The risk is the other way round: deleting a file someone still links to. Nothing is being deleted until it is answered.

Asked: Raised 2026-08-02.

Q20 Is example 3 a 77 inch part or a 77 mm part? It has no $INSUNITS and 77.3 units across.

Theirs because 77.3 mm is an ordinary part and so is 77.3 inches. Nothing in the file decides it; only whoever drew it can.

Waits on the answer

• ex3 — units.detected is recorded observed with a note not to promote it to a rule.
• spec-checks — Unit detection is stated as an automatic check on every file; here it is a default, not a detection.

assumed, and shipping dxf_io.to_inches calls it inches purely because our under-200 rule says so. The corpus records that as an observation and refuses to make it a requirement. If it is millimetres, every number we hold for ex3 is out by 25.4.

Asked: 2026-08-06, from the first corpus run.

Q21 Two artifacts are consumed by record pins and produced by none -- cut-order and true-size. Retype the producing pins as records, or leave the holes standing?

Theirs because The pin list tracks the work and does not commission it. Changing a pin's type is a statement about the record, which is his.

Waits on the answer

• cut-order — Consumed by spec-gcode, post-dialect and master-path-resume; produced by no record pin, though the code orders cuts.
• true-size — Consumed by vector-frontend; produced by no record pin. Also waits on Q1.
• pins-to-interface — The pipeline view reports six holes and cannot say which of these two are code gaps and which are record gaps.

two records disagree The hole grade says it exactly: either the code does not produce it, or it does and this list never said so -- and the list cannot tell you which. That is the whole disease the type system was added to cure.

Asked: 2026-08-02 audit; carried since.

Q22 When the fidelity search finds no counterpart for a point, how should a deliberately dropped speck report differently from a genuinely lost feature?

Theirs because It is the design of the one number a customer reads. We can implement any answer; which one is honest is his.

Waits on the answer

• D20 — Deliberately unfixed because the fix has this decision inside it.
• def-fidelity — What the headline number is allowed to mean.
• speck-drop — Dropping sub-thou dirt is correct behaviour and currently reports as a fidelity failure.
• ex11 — heal.dev_thou recorded as 1e+21 -- the sentinel, wearing a measurement's units.

assumed, and shipping heal.max_deviation returns its not-found marker 1e18 as if it were a distance and every caller multiplies it by 1000, so the board banner can read 1e+21 thou. On ex11 the cause is a 0.16 thou scrap of CAD dirt the healer is right to drop -- which is the point: the number cannot tell that apart from a whole contour going missing.

Asked: 2026-08-06, registering D20.

Q26 What standoff hardware do we actually use -- barrel diameter and screw -- and does a raised plate get a screw through its face or a stud welded on the back?

Theirs because It is what the shop stocks and how the shop fixes it. We can measure where a spacer CAN go; we cannot invent which one is in the drawer.

Waits on the answer

• build_mvt_preview.py:SPACER_OD_IN — The barrel diameter decides the smallest overlap a spacer can land on, and how far it must stay from a plate it passes.
• build_mvt_preview.py:SPACER_HOLE_IN — The hole is what we cut. It is also below the pierce standoff, so the answer decides whether it is drilled or pierced and listed.
• build_mvt_preview.py:MIN_WEB_IN — The web is the gate that PLACES every site on options B and C.

assumed, and shipping A 0.5 in barrel with a #10 clearance hole and a 3 x thickness web. Every site on both sheets is placed by those three numbers and both sheets say they are unconfirmed. The face-vs-stud half is stated to the customer as the one detail still to settle, because it is the only part of the mounting that shows.

We propose Name the barrel and screw you stock and we fix the table; the geometry re-sites itself.

Asked: cadmaster, 2026-08-06: siting the spacers for MVT options B and C. The hole positions are decided by the barrel diameter and the metal left round its hole, so the sheet cannot place a hole without assuming hardware.

Q1 For .ai/PDF art that carries no real-world size: do we tell customers to set the document to inches and draw 1:1 at actual cut size, require a finished dimension stated at upload, or require both and cross-check them?

Theirs because It is a customer-facing convention, and no measurement can settle it. Both .ai files we hold carry a 612x792 pt Letter artboard -- the application default, which tells us nothing about how big the part should be.

Waits on the answer

• scale-gate — The gate is built and the convention behind it is not chosen. The pin exists to hold this question.
• vector-frontend — Built, wired and measured end to end, and still cannot send a job to the floor.
• uploader — The required-field list on the upload form cannot be settled until we know whether a stated dimension is mandatory.
• true-size — Consumed by a record pin, produced by none. One of the two unrecorded holes in the pipeline view.
• scale stage — The whole stage is one decision wide.
• eagles — Runs only because we typed a width and marked it assumed.

blocked vec_pipeline.read() raises ScaleUnknown unless exactly one of width_in or scale is supplied (vec_pipeline.py:128). Every .ai in the corpus runs on a size a human typed. A wrong answer here does not make a slightly worse part, it makes scrap.

We propose Do both and cross-check: ship the Illustrator template AND require a stated finished dimension, then stop and ask whenever stated divided by measured is not 1.000. That is already the recommendation written on pin 14b; it needs a yes, not a design.

Asked: 2026-08-01, Aristide, during the vector front-end work: "we should check for an indicator for a scaling. And if it's missing, we would need to flag it and ask it."

Q3 How does a file tell us a path is engrave/score rather than cut -- layer name, stroke colour, or both?

Theirs because It is a convention we impose on customers, and Jordan has explicitly told us to hold no rule until an engraving file arrives: "We simply have not ever given you the engraving instructions on any of the files we've been testing with. You should have no rule at this point."

Waits on the answer

• cut-engrave — The pin is the question.
• qc1 — Its gate FAILs on open contours. That cannot go global while an engrave stroke may legitimately be open.
• intake stage — Nothing classifies a path at read time.

no rule held There is no engrave branch anywhere in the pipeline -- checked. Two facts are settled and cost nothing to hold: engraving carries no tipping weight, and all engraving runs before any cuts. What is missing is only the marking convention, and no file we hold contains engraving to learn it from.

Asked: Standing since the cut-vs-engrave pin was written; narrowed by Jordan 2026-08-04.

Q6 Which material and thickness is the reference case -- 0.060 stainless or 0.125 mild steel?

Theirs because It is a decision about which of two real test cuts we treat as the base row, and both came from the shop.

Waits on the answer

• slug-tab-rules — The slug-tab bands are validated on 0.125 steel only, and say so.
• bridges — Jordan's starting bridge widths were given for .060 stainless.
• D4 — The DXF board contradicts itself about material thickness -- this question is upstream of the fix.
• build_board.py:THICK — 0.060 with no stated source, on a board whose production post is MSO7,0.125.

two records disagree The DXF board reviews bridges at 0.060 and posts G-code at 0.125 on the same page. Registered as D4 and deliberately unfixed, because choosing a number would be answering this question ourselves.

Asked: Standing. The two bodies of shop knowledge we hold are on different materials.

Q7 What are the shop codes for copper, aluminium and stainless? Every file we hold says MSO7.

Theirs because They are strings from the control's own condition table. We cannot invent one, and a wrong code selects the wrong cutting condition.

Waits on the answer

• table-format — One of the three questions this pin is still open for.
• tables-built — materials.json has four rows and all four are MSO7.
• material-table — Only steel is in it.
• post stage — M100[<code>,<thickness>] cannot be emitted for any other material.

blocked tables.py raises MaterialUnknown on a miss rather than falling back to a neighbouring row -- which is right, and means cadmaster today posts steel and nothing else.

Asked: 2026-08-04, when the material table was built.

Q8 May a material row ever match a RANGE of thicknesses rather than one exact value?

Theirs because It is the question of whether shop numbers interpolate. Only the floor knows whether 0.135 stock cuts like 0.125.

Waits on the answer

• table-format — Second of the three open questions on the pin.
• material-table — Exact match today; a thickness we have never tested raises rather than guessing.

no rule held No bands. Exact match only. The lead-length rule already scales with thickness because Jordan stated it as a rule; slug-tab widths do not, and there is no evidence yet that they should. Inventing a tab width for an untested thickness is the exact failure the table exists to stop.

Asked: 2026-08-04, when the material table was built.

Q10 Which pierce subprogram does a job call for a given material and thickness? We hardcode 9011 and there are at least 9008 and 9035 as well.

Theirs because Vendor firmware selected from the condition tables. Mitsubishi's own recommendation is that these are set only from the tables, so the mapping is the shop's, not ours.

Waits on the answer

• await-mcode-glossary — The one thing still outstanding from the glossary, and a better question than the one it replaced.
• post-dialect — Every program we post calls the same subprogram.
• material-table — Where the mapping belongs once it exists.
• post stage — M98P9011 goes out on all 91 boundaries.

assumed, and shipping pierce_sub defaults to 9011 in emit.py:1178 and is emitted at emit.py:1600. It matches the shop's own master NC for 1/8 steel, so it is right for the one case we have tested and unexamined for every other. Jordan's framing stands over it: "We are doing this mostly to learn methodology not defining exclusive business rules yet."

Asked: 2026-08-04, put to Jordan with the O9011 answer.

Q11 Are the M1xx condition-select codes and the #1xx condition variables the same table?

Theirs because It is a fact about the control. The glossary says nothing about the relationship and we would only be guessing from adjacency.

Waits on the answer

• await-mcode-glossary — Flagged on the pin specifically so it is not quietly assumed.
• post-dialect — We emit ten condition variables while selecting condition set 1, and cannot say whether that is consistent.

no rule held No link is assumed anywhere in the code. The master sets #102-#111 and #121/#122 while selecting only set 1, so the numbers being adjacent is all we have. Recorded as a temptation, not as a finding.

Asked: 2026-08-03, from the machine's own G/M list.

Q12 M124/M125 corner control and M140/M141 spatter-preventing spray exist on the control and neither shop file uses them. Is that a choice, or does the machine not have the option?

Theirs because Only the operator knows whether an option is fitted.

Waits on the answer

• await-mcode-glossary — Noted from the glossary; nobody has asked.
• machine-time — Corner control changes cut time, if it is available at all.

nothing built on it We emit neither, which matches both shop programs exactly. No cost today. It matters the first time a job needs corner control and we do not know it exists.

Asked: 2026-08-03, from the code census.

Q13 Do you expect kerf to open up with thickness? Every program we hold is D7 / .007 from 0.060 through 0.990.

Theirs because If the shop expects kerf to grow and the files say it does not, one of the two is wrong, and only he can say which.

Waits on the answer

• tables-built — Four material rows, one kerf value, recorded as a measurement because that is what the programs say.
• materials.json:MSO7,0.990 kerf — Recorded measured, at .007 -- the same value as the 0.060 row, sixteen times thinner.
• post stage — G41 with a D-offset on every boundary.

assumed, and shipping materials.json carries .007 at every thickness because every program we have been given carries .007 at every thickness. That is a measurement honestly recorded -- and it is also the kind of constant that turns out to be a post-processor default rather than a physical fact.

Asked: 2026-08-05, from the material table work.

Q14 Does a strip roughly 1.6 by 0.20 inches, cut on both sides in 1/8 steel, stay flat or bow?

Theirs because Heat and residual stress on a thin ligament. It is a shop observation, not a calculation, and our stiffness numbers rest on handbook values anyway (Q15).

Waits on the answer

• mvt-preview — A customer sheet claim about whether a joined option holds its shape.
• assembly-connectivity — The width of an added weld chord depends on the answer.

nothing built on it Nothing claims it either way. The question was raised and never put to him.

Asked: 2026-08-05, out of the MVT geometry work.

Q15 Can the shop confirm yield 36000 psi, E 29e6 psi and density 0.284 lb/in3 for the stock actually used -- or give the real numbers?

Theirs because They are handbook A36 figures nobody at the shop has ever confirmed, and they are the foundation of every physical claim we put in front of a customer.

Waits on the answer

• build_mvt_preview.py:SY — Every bend claim on a customer sheet rests on it.
• build_mvt_preview.py:E — Every stiffness claim. Steel's E is genuinely consistent, so this is the safest of the three.
• build_mvt_preview.py:RHO — Every weight in pounds we have ever quoted.
• client-shop-split — The shop sheet is meant to show the engineering behind every customer claim; behind these three is a handbook.

assumed, and shipping All three are in the output now and are marked assumed in the evidence register. "15.30 lb" reached a customer sheet on a density nobody measured.

Asked: 2026-08-05, from the evidence register.

Q16 Snap gaps at or under 0.5 thou, flag from there to 60 thou -- are those the right numbers, and should the snap stay silent?

Theirs because It decides what we silently change in a customer's drawing. That is not ours to set by default.

Waits on the answer

• autoclose — The pin is the question.
• qc2 — Reporting what was stitched or closed is QC step 2's job, and it is not built.
• heal stage — Both thresholds run unconditionally on every heal.

assumed, and shipping dxf_io.stitch_open_polylines joins fragment ends within 1.0e-4 in; heal.close_micro_gaps bridges up to EPS_DROP = 5.0e-4 in (heal.py:456); qc.GAP_FLAG = 0.060 (qc.py:26) is the flag side. All three run on every file and nothing tells the operator how many fragments were stitched or how many gaps were closed.

Asked: Standing on the auto-close pin; the numbers were chosen in code, never ruled on.

Q17 The estimator blocker list -- cut feed rates, pierce times, rapid rate, machine hourly rate, sheet cost, drop policy, handling times, minimum charge, and how you price today.

Theirs because None of it is inferable from geometry. Every number is commercial and the shop's alone.

Waits on the answer

• estimator-inputs — The pin is the list.
• estimator — Arithmetic on numbers we already compute, times rates we do not have.
• quote-cost-model — The build-up cannot be checked against anything.
• report stage — No quote is produced.

nothing built on it Nothing is built and deliberately so -- anything built now would be a demo. The single most valuable item is not a rate at all: a handful of jobs already quoted and already cut, with what was charged and what it actually took.

Asked: Standing on the estimator pin.

Q26 What standoff hardware do we actually use -- barrel diameter and screw -- and does a raised plate get a screw through its face or a stud welded on the back?

Theirs because It is what the shop stocks and how the shop fixes it. We can measure where a spacer CAN go; we cannot invent which one is in the drawer.

Waits on the answer

• build_mvt_preview.py:SPACER_OD_IN — The barrel diameter decides the smallest overlap a spacer can land on, and how far it must stay from a plate it passes.
• build_mvt_preview.py:SPACER_HOLE_IN — The hole is what we cut. It is also below the pierce standoff, so the answer decides whether it is drilled or pierced and listed.
• build_mvt_preview.py:MIN_WEB_IN — The web is the gate that PLACES every site on options B and C.

assumed, and shipping A 0.5 in barrel with a #10 clearance hole and a 3 x thickness web. Every site on both sheets is placed by those three numbers and both sheets say they are unconfirmed. The face-vs-stud half is stated to the customer as the one detail still to settle, because it is the only part of the mounting that shows.

We propose Name the barrel and screw you stock and we fix the table; the geometry re-sites itself.

Asked: cadmaster, 2026-08-06: siting the spacers for MVT options B and C. The hole positions are decided by the barrel diameter and the metal left round its hole, so the sheet cannot place a hole without assuming hardware.

Q28 What is the smallest hole the laser can cut with a centre pierce and no lead, per material x thickness?

Theirs because It is a number that lives in the steel and the nozzle -- how big the pierce crater is and how close to it a wall survives. Nothing we hold measures it: the smallest circle in the proven MSO7,0.125 programs is 0.3126 in and lead-cut.

Waits on the answer

• materials.json:MSO7,0.125.min_pierce_hole — Assumed at one material thickness (0.125 in). Jordan's number replaces it and re-sizes every centre-pierced hole we emit.
• cadmaster/mvt_sheet.py — Tie holes are max(strap function floor 0.110, this value) -- today 1/8 in. A smaller confirmed floor shrinks them to the function floor and no further.

assumed, and shipping The MVT sheet cuts 5/32-was, now 1/8 in tie holes from the assumed floor. The washer bores (0.219) sit above it either way.

We propose One material thickness, rounded to the machinist fraction at or above it -- 0.125 for 1/8 steel -- until the shop measures it. A test row of centre-pierced holes at 0.090 / 0.100 / 0.125 in scrap of each running material would replace the assumption with a bracket in one cut, same shape as the slug-tab table's derivation.

Asked: Aristide, 2026-08-07, on the MVT tie holes: "the smallest holes we can cut, with piercing, would work in my opinion." The function floor is the 2.5 mm zip-tie strap (0.110 in diagonal); the process floor is this question.

Q2 What does EAGLES.ai actually cut at? Our 12 inch width is our own guess.

Theirs because Only the person who ordered it knows. It is the concrete instance of Q1, which is why it is listed separately: Q1 is the policy, this is one file waiting.

Waits on the answer

• eagles — width_in 12.0 is recorded as an assumption; every dimension the corpus records for this file is scaled by it.
• cadmaster/viewer/eagle — The published eagle board states sizes derived from the guess.

assumed, and shipping 12 inches, chosen by us. Everything on the eagle board -- extents, bed check, feature sizes -- is that guess multiplied out. The numbers are internally consistent and may all be wrong by one factor.

Asked: 2026-08-01, when the file was first read -- it has no stated size.

Q20 Is example 3 a 77 inch part or a 77 mm part? It has no $INSUNITS and 77.3 units across.

Theirs because 77.3 mm is an ordinary part and so is 77.3 inches. Nothing in the file decides it; only whoever drew it can.

Waits on the answer

• ex3 — units.detected is recorded observed with a note not to promote it to a rule.
• spec-checks — Unit detection is stated as an automatic check on every file; here it is a default, not a detection.

assumed, and shipping dxf_io.to_inches calls it inches purely because our under-200 rule says so. The corpus records that as an observation and refuses to make it a requirement. If it is millimetres, every number we hold for ex3 is out by 25.4.

Asked: 2026-08-06, from the first corpus run.

Q23 What is inside subprogram O9011? We call it about 91 times per program and have never seen it.

Theirs because It is the control's own file.

no rule held Answered.

Answered — Jordan, 2026-08-04. "O9011, 9008, 9035, and more you'll see are pierce subprograms. Rule of thumb with Mitsubishi is any program starting with a 9 is their proprietary subprogram and they recommend that we only set these with the tables." So we are not meant to read it: it is vendor firmware selected from the condition tables, not something we author. The worry was misplaced. It leaves a better question in its place -- Q10, which one to call.

Asked: Standing for a fortnight; put to Jordan 2026-08-04.

Q24 Is M121 a cutter-comp code, or the end of a program?

Theirs because A fact about the control and about how the shop writes a program.

no rule held Answered.

Answered — Jordan, 2026-08-04. "To be clear, M121 & M87 don't have anything to do with cutter comp." M121 ends a PART, M87 ends a FEATURE -- which against the master NC is exactly the 90-to-1 split we had measured and misread as a comp rule. Defect D13 was raised on the wrong reading and the rule is now stated well enough to fix it.

Asked: Raised when our post keyed the end-of-boundary code on comp state.

Q25 Can we have the control's M-code glossary?

Theirs because It is the machine's own documentation.

no rule held Answered.

Answered — Aristide, 2026-08-03. Supplied as four photographs of the control's own scrolling G and M list, transcribed into machine_codes.json with the images kept in incoming/ as the primary evidence. Jordan then ruled code by code on 2026-08-04. The census found nothing outside the documented vocabulary in any of the three programs. Listed here because the hand-written open-questions file still carried it as open three days later -- the same drift the pin types exist to stop.

Asked: Jordan, 2026-07-29: "I will look for an M-code glossary and upload when able. Put a reminder for me in the edit file."

Q27 Below what size is a drawn feature no longer a feature -- and when we drop one, do we keep the corner it sits on or round it?

Theirs because It is a call about what the customer is owed, not a measurement. Jordan raised it and it decides whether a brush-script terminal stays a point or becomes a radius.

Waits on the answer

• heal.py:TOL — Whether the smoothing floor is the acceptance gate, a stated fraction of it, or the kerf -- three different numbers that are currently one.
• cadmaster/heal.py — A sub-tolerance simplification stage before the fit; today the fitter honours every drawn feature however small and the kinks are argued about afterwards.

nothing built on it Answered. The ruling is in CLAUDE.md and pin spec-healing; the pass itself is not built, so the Brazen board still shows FAIL with 261 sub-kerf kinks.

We propose Key the floor to the DEVIATION that dropping a feature causes, not to the feature's own size, and spend a stated fraction of the gate on it rather than the whole gate -- 20%, so 0.002 in at the 0.010 gate, leaving the rest for the fit. Drop the whisker but KEEP the corner it sits on: a brush-script terminal is a point in the letterform, and rounding it is a visible change the customer did not ask for. Floor stays absolute at CUT size, so a part scaled up keeps features a small one loses, and rescaling a job re-runs the pass.

Answered — Jordan, 2026-08-06. Jordan, 2026-08-06, all five: (1) “If we fall within the tolerance then smoothing is acceptable and you can be less verbose about it. Put that in ClaudeMD.” — a true source corner MAY be rounded inside the budget; cadmaster's keep-the-corner-always proposal overruled. (2) The floor is “below the tolerance that the operator sets, in this case 10 thou”; on the 20%-of-gate proposal, “not that bad, but might be a bit tight.” (3) Deviation-keyed, not size-keyed: “Correct.” (4) The scaling point was about visibility, not about a scaling floor: “since the part is so small, these small details (less than 10 thou) will be invisible to the customer.” (5) Same as (1) — sub-kerf entities go, reported briefly. cadmaster's call on the share Jordan left open: no fixed fraction. Smoothing and fitting spend ONE budget and the binding number is the measured end-to-end deviation from the true source that the board already reports; design target for the smoothing share is half the gate. Two numbers that cannot be reconciled is the failure mode the fixed fraction was inviting.

Asked: Jordan, 2026-08-06: "Since this file is so small, you need to accommodate for scaling. When we get below our tolerance (this case 10 thou) these features which are smaller than our tolerance can be smoothed out." Measured on the Brazen plate the same day: all 261 remaining fit-induced kinks sit at a junction with a primitive shorter than 0.005 in and 184 of them shorter than 0.001 in, median 0.0007 in. Control: the same is true of 45% of the 2372 clean junctions, median 0.0078 in -- so a short primitive is NECESSARY for a kink here but not sufficient, and a blanket sub-tolerance pass would touch roughly half the file's junctions, not just the 261 that are wrong. Scale of the prize: of 2633 healed primitives, 1273 (48%) are shorter than the 0.007 kerf and together carry 1.85 in of 62.46 in of path, 3.0%.

Q29 What single dollar figure does the customer approve, composed how from the 15a line items -- which times take the hourly rate (cut only, or handling too), where the margin applies, and where the shop minimum sits in the order of operations?

Theirs because It is pricing policy, not a measurement -- how the shop charges, not what the machine does. Aristide owns the customer-facing convention; Jordan knows how the floor actually bills.

Waits on the answer

• customer-portal — The approval sheet's price item can never reach FIRM: the artifact honestly says 'price to follow' and overall status stays NOT YET READY, even once Jordan's rate rows land.

assumed, and shipping All ten policy knobs are live per-shop fields in the shop tables editor (enums included); handling bills at a separate operator rate whose value is OWED, so quote.py's roll-up now correctly lists policy.operator_hourly_rate_usd among blocked_by until Jordan fills his shop's rate. FIRM still waits on the rate rows themselves.

We propose REFRAMED (Aristide 2026-08-21: 'what would our customers want, flexibility wise? We aren't just building this for Jordan... We want our clients to have a flexible system') and EXECUTION STARTED same day on his order ('start execution on moving on without waiting for Jordan'): the roll-up is now PER-SHOP POLICY, not one ruled formula. rollup.py composes the 15a items through a fixed skeleton with switchable joints -- cutting_basis (time | per_inch*), handling_bills_at (machine_hourly | operator_hourly | included_in_margin), material_markup_pct, rush_multiplier, minimum_applies (before_margin | after_margin), rounding -- each joint a policy row in rates.json, editable in the shop tables editor, seeded 'assumed'. (*per_inch blocks until per-inch rate columns exist -- a schema request.) Deliberately NOT a freeform formula editor: joints are enumerated so every figure stays accountable. Deferred, recorded: quantity breaks (need nest part-count), rush tiers (presentation over the multiplier). WHAT REMAINS OF Q29: Aristide/Jordan confirm or override the knob DEFAULTS -- their ruling becomes the default config a subscriber inherits. Status can never reach firm while any consumed row or knob is assumed: rollup names the culprit rows on every figure.

Answered — Aristide, 2026-08-21. Every knob is a PER-SHOP TABLE VARIABLE -- none gets a ruled value. Verbatim: 'remember, we cannot force our customers that buy the software to work the way we want, we need to be flexible.' Item by item: (4) handling -- 'it is a separate line item in the table that needs to be filled out. Customers must be able to set the rates. (and so does Jordan)' -> handling_bills_at = operator_hourly (decided), operator_hourly_rate_usd an OWED row each shop fills; (5) shop-minimum order -- 'also a decision per customer, make it variable in table'; (6a-6d) material markup, rush multiplier, rounding, cutting basis -- each 'needs to be a variable'. Defaults stay SEEDS a shop overrides; Aristide deliberately signed off none of the numbers. Jordan's override on any of it stays open (equal authority).

Asked: 2026-08-21, surfaced building the approval artifact (7g piece 4): the quote engine prices each line item separately by design, but the approval sheet's price approve-item needs ONE figure, and no roll-up from items to a total has been ruled.

Q30 STEP files have arrived (first ever: Jordan's ISV-H front-grille package, 2026-08-21 -- 9 SolidWorks AP214 exports, every part BENT sheet metal). What is kerfmaster's job when the input is a 3D STEP: (a) reference only -- the shop/customer unfolds to flat DXF as today, we optionally VERIFY the DXF against the STEP (hole counts/diameters, flat dims); (b) kerfmaster unfolds -- flat pattern from the solid with bend allowance/K-factor per material x thickness (real new engineering; MetaCam cannot do it either); or (c) file with the job, no processing?

Theirs because Jordan owns the shop workflow (who unfolds today, what K-factors the press brake actually uses); Aristide owns product scope (is STEP-unfold a kerfmaster capability or out of scope).

no rule held No STEP reader in the pipeline. The batch is inventoried and archived with the job; the flat DXF path works as always.

Answered — Jordan, 2026-08-21. His commissioning message answers the role question in practice: 'Here are step files that were supplied to us, and dxf files that we unfolded in SolidWorks. BNM78880 was too bad so we were unable to unfold it, so see if you can using the others as examples.' So: the customer sends STEP, the SHOP unfolds to flat DXF in SolidWorks, and the flat DXF is the cut authority -- option (a) as the norm. kerfmaster's role in 3D is UNFOLD BACKSTOP (option b) when SolidWorks fails, calibrating bend allowance from the six STEP+DXF pairs of the same batch; the 78880 result cuts only after Jordan approves its board. (This entry absorbs a duplicate Q30 'step-3d-input-role' recorded the same day -- same question, asked twice across sessions.)

Asked: 2026-08-21, on receipt of the batch. Probed by hand-parsing: all 9 are single-solid sheet-metal parts; cylinder-axis test separates holes (axis along sheet normal) from bends (axis in sheet plane) -- every part carries bends, radii ~1.91/3.82 mm = one and two thicknesses of 14 ga. The BNM76282.DXF delivered as build 028 is evidently the unfolded flat of the grille panel.