8. Cut vs. engrave rule

kerfmaster pin list · UI / workflow decisions

questionmixedUnresolved, waiting on Aristide or Jordan.

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

Contract — Intake stage

This contract is unresolved — the gate below is the thing waiting on an answer.

takes raw-geometry

makes —

fails if Engrave geometry cut clean through, or cut geometry engraved — with no rule held, either is currently possible.

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

1 open question blocks this pin

Q3 How does a file tell us a path is engrave/score rather than cut -- layer name, stroke colour, or both?
Aristide, Jordan — The pin is the question.

Before ‘open contour = FAIL’ can go global, cadmaster has to know which paths are cut and which are engrave/score — because an engrave pass may legitimately be open and must not false-fail.

How a file could mark it

Layer name — e.g. CUT / ENGRAVE layers in the DXF. Explicit, easy to read.
Stroke color — the natural signal for vector art (red=cut, blue=engrave, …); ties to the .ai/vector input item (2a), where color is the future cut/engrave/score channel.

Why it matters

Open-contour QC only means FAIL for CUT boundaries — engrave strokes are meant to be open.

⚑ Team decision (Aristide + Jordan): pick the convention — layer names, colors, or both — and we standardise it end to end.

There is no engraving in anything we have been given — Jordan, 2026-08-04

Put to him directly, because our own record said cut versus engrave was decided by whether cutter comp was on, and his files contradicted it: 90 of 91 CUT boundaries in the master NC are G40. His answer removes the premise rather than correcting the rule:

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.

So the comp-state inference is deleted, not amended. It was never something the shop told us; it was something we inferred from a body of files that happens to contain no engraving at all. G40 on a cut boundary is a comp declaration (item 4a) and says nothing about cut versus engrave. Nothing in the code implemented it — checked, there is no engrave branch anywhere in the pipeline — so this was a wrong line in the record only. It also closes contradiction G3 from the 2026-08-02 audit.

Two facts we do now have

Engraving carries no tipping weight. Jordan: "any 'engraving' will not have repercussions for flyover, crossing, etc. Good news about that will be that it will have no weight in the decision making in regards to tipping potential." An engraved path does not sever anything, so it creates no loose piece and no hazard — it is invisible to item 4e's metric on both sides: it is not a thing you can tip, and passing over one is free.
Order: all engraving first, before any cuts. Jordan's rule of thumb. It follows from the first fact — engrave while the sheet is still whole and nothing is loose, because afterwards every move has to respect held slugs.

Still open, and unchanged: how a file marks a path as engrave. That is the question this item exists for and Jordan's answer does not settle it — layer name, stroke colour, or both. Until an engraving file arrives we have no evidence either way, and per his instruction we hold no rule rather than guess one.