willtools-demo/docs/ticket-checklist.md

What to check on a shop ticket

Developed 2026-08-27 from a real audit of twelve pieces (WP194, 195, 196, 199, 200, 210, 213, 214, 215, 219, 220, 412 — all design WP1) against the model they were drawn from. Every item below is either something the existing checks already do, something the audit found they get wrong, or something nobody was checking.

The organising question for each item is not "is this checkable" but what does it take to check it, because that decides whether it can be code:

grade	meaning
A	pure code. Two values exist in the model; compare them.
B	code, once a plant fact is written down. The rule is mechanical, the constant is local knowledge.
C	code can narrow it to a shortlist; a person decides.
D	a person reads the drawing. Code can only make sure they were asked.

---

0. Before any of it: find the whole ticket

A ticket is not one sheet. In this model 97 tickets are 1 OF 2 + 2 OF 2 under the same sheet name, and 9 are 1 OF 1. The two sheets carry different things:

sheet	carries
1 OF 2	Elevation Top (the BED PLAN, with the embed callouts), the TICKET NOTE views, the strand jacking force
2 OF 2	Elevation Front, Elevation Right — and the strand count lives in Right

Reading one sheet and calling it the ticket is how the audit produced 60 findings that were not real. Grade A — collect every sheet whose name equals the mark, and treat their union as the ticket.

---

1. Identity — is this ticket about this piece

#	check	grade
1.1	Sheet name equals the piece mark	A
1.2	Sheet's design-number parameter reduces to the piece's design	A
1.3	Exactly one ticket set per piece — no orphan sheet, no duplicate	A
1.4	Every placed view's name refers to this design.	A B (re-graded 2026-08-30)
1.5	Printed call-outs do not overlap each other.	C (new 2026-08-30)

1.5 — two call-outs printed on top of each other

Text-bearing annotations — text notes, tags, keynotes — on the same placed view, whose view-space bounding boxes intersect with positive area. WARN, naming both texts and the size of the overlap (CALLOUT-OVERLAP, ticketpage.callout_overlap_status).

Text against linework is deliberately out of scope, and that is a ruling, not an omission. A call-out printed over a drawn edge is the normal condition on every elevation on every ticket; flagging it would report the whole sheet and teach the reader to skip the row. Only text against text is asked.

Two honesty limits, and the check states both in its own reporting.

1. A bounding box approximates the printed extent. It carries the text's leading and side bearings, so it is a little larger than the ink, and a small intersection can be two notes that print clear of each other. That is why the message states the overlap size in printed inches, and why this is grade C: the check narrows the sheet to the pairs worth looking at, and a person decides. It is never a defect claim.
2. Rotated text reports an axis-aligned box, which circumscribes the rotated glyphs and overstates the ink by up to the length of the string. Those pairs are set aside, not flagged — reported under CALLOUT-OVERLAP-UNREAD at OK severity, named, so they can neither masquerade as a finding nor silently disappear. An annotation whose rotation cannot be read at all is set aside the same way: unknown is not the same as zero.

Boxes are converted to printed inches through the view's scale, because inches on paper is the only unit a reader can act on. Verified against the live model: a DUNNAGE note on a 1:96 view boxes 5.198 x 2.156 ft, which prints 0.65" x 0.27" — the size of the word.

Measured before it was built (bridge read, 2026-08-30, one WP ticket): get_BoundingBox(view) returned non-null for 22 of 22 text notes, and zero pairs overlapped across all seven placed views. So on a good sheet this row is quiet, and a finding is signal rather than noise — which is the condition a WARN-only check has to meet before it is worth adding.

1.4 is new and came out of the audit. A view named TICKET NOTE - WP2- STRAND JACKING FORCE is placed on 100 sheets, all of them WP1 pieces. Reading the content settled it — 0.70 fpu = 28.9 kips is WP1's own number, so the note is right and the name is a leftover. That is the point: a stale name on a correct note is a trap for the next person, and the check is one string comparison. Report the name mismatch; never infer the content is wrong from it.

Re-graded A -> B, 2026-08-30, built the same day (VIEW-DSN, ticketpage.view_name_design_status). Two reasons, and the first is the weaker one:

1. It is not one string comparison. Recognising that WP2 inside TICKET NOTE - WP2- STRAND JACKING FORCE is a design label at all needs the plant's design-token pattern, and comparing it needs the same suffix reduction 1.2 uses (PNL1.0 and PNL1 are one design). That is "mechanical rule, local constant" — the definition of B. The pattern is derived from nomenclature.design_number_re rather than added as a second plant fact, so nothing new has to be written down.
2. It is never worth failing a ticket over, and that is what settles it. This check sits in tension with a rule this project already holds: a view name does not identify a design. The check does not break that rule, it depends on it — the design comes from the sheet's design-number parameter, and 1.4 only reports a view that labels itself and labels itself wrongly. So a 1.4 finding is never evidence about the piece. The audit proved exactly that: the WP2-named note was WP1's own correct number. What it protects against is a reader, in both directions — someone believing a WP2 note on a WP1 sheet, or deleting a correct note because its name looked foreign. That is hygiene, WARN, grade B.

One deliberate blind spot: only a token whose letter prefix matches this design's is compared, or Elevation Top 2 reduces to TOP2 and every ticket grows a false finding. It can therefore miss a label from an entirely different piece family. For a WARN, silence is the right way to be wrong.

2. Dimensions and mass

#	check	grade
2.1	Printed length / width / depth vs modelled	B — on stemmed pieces the printed length is nominal and runs over by design, so the tolerance is a plant fact
2.2	Weight, three ways, all three must agree — see below	A
2.3	Unit weight on the ticket vs the design summary	A
2.4	Cast extras (a ledge is its own family) counted in the weight	A

2.2 — weight is a three-way agreement, not a comparison

Two numbers agreeing proves nothing about which one is right. Three independently derived numbers agreeing is evidence the piece is what everybody thinks it is, and any one of them disagreeing tells you where to look:

#	number	derived from
a	printed	the WEIGHT (lbs.) field in the ticket's title block
b	reconstructed	length x width x thickness, less the blockouts, plus the cast extras, x unit weight — the piece as the drawing describes it
c	measured	the actual volume of the modelled solid x unit weight — the piece as it was drawn

What each disagreement means:

• b and c agree, a differs — the model is consistent with itself and the ticket's weight field is stale or was overridden. The piece is probably fine and the print is wrong.
• a and b agree, c differs — the stated dimensions and the printed weight tell the same story but the solid does not match them. Something was modelled that the dimensions do not describe: an uncut opening, an unrecorded recess, a ledge, a chamfer taken too far.
• a and c agree, b differs — our reconstruction is wrong, which means our reading of the geometry is wrong: a blockout missed, a cast extra not counted, a thickness read from the wrong parameter. Suspect the tool first.

vibe.liftexport.weight_check already computes all three and calls them stated, reconstructed and solid. What it does not yet do is report the pattern of the disagreement, which is where the diagnosis is.

Both failure directions have been seen on this job. A slab-seat ledge left out of the reconstruction understated one piece by 7.5%, and the gate refused a model that was right — that is the third row. On four other pieces the _CAST volume parameter and the real solid differ by 14–15 ft3 in both directions, which is the second row, and it is a model-side problem.

Do not report a weight finding without saying which of the three disagrees.

2.4 — the extras the ticket draws vs the extras that were counted

Built 2026-08-30 (CAST-EXTRA, check_cast_extras / ticketpage.cast_extra_agreement). It is a different question from 2.2 and the difference is the whole reason it exists: 2.2 compares three weights, and all three can be wrong the same way. A ledge left out of the model AND off the drawing is missing from the printed weight, from the reconstruction and from the solid alike — they agree with each other, 2.2 says OK, and the piece is 7.5% light. 2.4 compares the set, not the number.

Telling the two sides apart. "The extras that were counted" is not a re-derivation: liftexport.extra_cast_ft3 was split so its member list (extra_cast_members) is the shared thing, and 2.4 reads exactly the members whose Volume fed 2.2's reconstructed weight. Two implementations of "which family is cast concrete" would drift; there is one. "The extras the ticket draws" is read from the ticket's words — a BOM row, or the text on a placed view, naming one of the same families.cast_include tokens.

That is a proxy and the check says so rather than implying otherwise: the ledge is drawn as geometry, and no query answers "does this elevation show a ledge". What 2.4 can honestly assert is that the two sides name the same extras.

Three findings it produces, none of them reachable from 2.2:

• the ticket names an extra the assembly does not carry — the case above;
• an extra is in the weight that nothing on the ticket names;
• a cast member whose Volume could not be read: it added nothing to the reconstruction, silently. Drawn, and not counted.

The five BOM states are respected, not collapsed (ticketpage.bom_state). OK and PARTIAL are judged, PARTIAL naming what failed. ABSENT is a fact about the ticket, so it is judged from view text and the message says that is all it had. UNREADABLE and UNKNOWN are failures of ours — the row that names the ledge may exist and we missed it — so "the ticket does not name it" is not assertable and the comparison stands down to NOT RUN with the BOM's own reason. The unreadable-volume finding still fires there, because it needs no ticket at all.

What it cannot detect, stated in the OK itself: an extra missing from both the model and the drawing. Nothing on either side is a genuine pass, but the message says out loud that the blind spot was not closed.

3. Concrete

#	check	grade
3.1	f'c on the ticket vs the design summary	A
3.2	f'ci on the ticket vs the design summary	A
3.3	f'ci / f'c release ratio inside the plant's band	B

The audit's f'c and f'ci findings were false. Both were raised as "in the summary, not found on the ticket" because the tool was reading only sheet 2 OF 2. Fix item 0 first or these two produce noise on every ticket.

4. Strand

#	check	grade
4.1	Printed strand count vs strands modelled	B — whether the printed (n) is per-piece or a design maximum is a plant fact
4.2	Printed diameter and grade vs the design	A
4.3	Jacking force on the ticket vs the design, within tolerances.it_lb (100 lb, owner 2026-08-30 — the same 0.1 kips the check always used, now a knob rather than a literal)	A
4.4	Strand positions vs the design's dimension chain, from the stated rail	B — which rail is fixed is plant knowledge and is never inferable
4.5	Debonded strands called out where the design debonds	C
4.6	Row count and spacing plausible for the section	A
4.7	Strand debonded wherever the concrete along it runs short	B — the length is a plant fact

4.4 — what "never inferable" does and does not forbid

The rule bars inferring which rail the design summary dimensions from. That is a plant fact and guessing it silently reverses every dimension in the chain.

It does not bar measuring from both edges. Strands get rotated during reinforcing, so the chain legitimately has to be tried against both sides and the fitting one kept. check_strand_layout does exactly that and is correct. Ruled by the engineer 2026-08-30, after this was raised as a possible violation. It was not one.

4.5 — does the ticket say so?

Built 2026-08-30 (STRAND-CALLOUT, check_debond_callout / ticketpage.debond_callout_status). Will's ruling, verbatim: "4.5 做掉。 如果满足 debond 要求，那么就期待有 debond，没有 debond 给个 warning。" — where the debond condition is met, expect a call-out; where there is none, WARN.

It does not re-derive the geometry. It consumes 4.7. Both items now read one _debond_requirement(t, know), cached on the ticket, so there is exactly one place that decides whether a run is short and the two items cannot disagree. Three consequences follow, all deliberate:

• If 4.7 could not judge, 4.5 cannot either. It returns nothing and its row reads NOT RUN repeating 4.7's own reason. Warning that a call-out is missing, when nothing established a requirement, would be inventing the requirement.
• If 4.7 judged and found nothing required, 4.5 is an OK that says so — not silence.
• A call-out where nothing is required is not flagged. Only one direction warns, because that is the ruling.

The ticket side is strand.debond_callout_tokens — plant nomenclature, empty by default, so a plant that has not written down its own wording gets NOT RUN with that reason and never a pass. Measured: this plant's BED PLAN prints a bare two-word note among the embed callouts, and the manufacturer's standards carry a whole note sheet whose entire content is a longer form of the same words.

Not merged with the manufacturer's own debond standard, which fixes a length at each end keyed on strand diameter. That is a bed standard; the threshold in 4.7 is a geometric trigger. Different rules, and the manual's fixed length must never be substituted for the threshold.

Still grade C, and the OK admits why. The call-out is a bare note: no station, no strand number. A present call-out is evidence that somebody debonded something, not that they debonded these runs — so the OK says, in those words, that it was not verified. Code narrows; a person closes it.

4.7 — a short run of concrete cannot develop a strand

Not the same question as 4.5. That one asks whether the ticket calls out the debonding the design specified; this one derives from the geometry where debonding is required, and can therefore catch a design that failed to specify it.

Along the strand direction, measure the runs of continuous concrete between openings. Where a run is shorter than strand.debond_below_continuous_ft (4 ft here), the strand crossing it must be debonded.

The reason decides the shape of the check, so it is worth stating. Openings leave little column sections. A strand crossing one has nowhere to develop — its transfer length exceeds the concrete available, so it never reaches force and carries essentially nothing. That alone would only be waste; the harm comes at release, when burning the strands drives a shock transfer through a stretch too short to take it, and a flexural crack opens.

Bursting steel answers part of the problem — the Poisson expansion as the strand shortens — but not this part. The instantaneous flexure from the bursting force has no detailing remedy. Debonding is the answer, which is why this is a rule and not a preference.

The geometry is already in hand: liftexport._openings returns every void as (x0, x1) along the length, and the ROW-FLEX work already cuts the piece at every opening edge. The uncut runs between those cuts are exactly what this measures.

On 4.1 the audit found five of the twelve print (14) while 10 or 6 are modelled. That is a real discrepancy to put in front of a person; it is not automatically a defect, because the printed count may be the design's maximum.

Where the strand data actually is: the count is inside the Elevation Right detail view ((14) 0010001 (E.L.)), and the jacking force is in a TICKET NOTE view. There is no separate pattern-legend view on any of the 204 WP sheets in this model. The existing LGD-MISSING check looks for a placed view whose name starts with STRAND PATTERN or REINFORCING PATTERN; it fires on every WP ticket and always will. Either the prefixes are wrong for this plant or the concept does not apply here — it is a knowledge-file question, not 204 defects.

Answered, Phase 2: the concept does not apply. legend.pattern_prefixes is empty for this plant and LGD-MISSING now asks about the BOM schedule instead, so the 204 false positives are gone. Two things about it are still open — a "could not read the BOM" that reports as a defect, and the fact that no checklist item owns LGD-* so neither verdict reaches the report table. Both are written up in docs/checklist-code-map.md.

5. Reinforcing and embeds

#	check	grade
5.1	Every embed on the BED PLAN callouts exists in the model — two halves, one of them unbuilt and saying so (2026-08-30)	A
5.2	Every embed in the model appears on the ticket	A
5.3	Face designations (N.F. / F.F. / E.L. / S.I.F.) consistent with the model side	C
5.4	Mesh / WWF designation vs the design	A
5.5	Bar marks legible on the drawing	D
5.6	Bar marks unique, and model and print name the same bars	B (new 2026-08-30)
5.7	No bar longer than the stock it is cut from	B (new 2026-08-30)
5.8	Connectors present on an insulated panel	B (built 2026-08-31)
5.9	Enough connectors for what the design calls for	B (built 2026-08-31)
5.10	Connector edge distances	B (built 2026-08-31)
5.11	Every lifter's solid zone is a member of the assembly	B (built 2026-08-31)
5.12	Solid zones appear on the ticket's insulation layout	B (built 2026-08-31)
5.13	Solid zone hatch matches the legend swatch	B (built 2026-08-31)
5.14	Insulation recess regions present where the design calls for them	C (built 2026-08-31)
5.15	Recess region hatch matches the legend swatch	B (built 2026-08-31)

5.1 asks two questions and only one of them was ever asked (2026-08-30)

docs/checklist-code-map.md has said for a while that 5.1's owner code does not implement 5.1 as written: check_bom_members compares the BOM's named rows against the assembly's members, which is a real comparison and not the BED-PLAN one this row describes. The row printed OK off it anyway.

The half that was missing has a shape nobody had written down. Not every call-out on the BED PLAN is a part. This plant collects its typical sections onto detail sheets of their own and the plan cites one as a bubble — a detail number over a sheet name — whose embeds are drawn there and never on the plan. nomenclature.detail_sheet_prefix is the plant naming that series, and it is the only thing that tells a bubble from a part call-out. It was declared in the plant file, documented, and read by nothing (D5 in QNA/drift-triage.md). The owner's ruling was one line: "那倒是读啊。。"

It is read now, and what it buys is exactly one thing: the ability to see that the plan reaches past itself. Nothing here opens a detail sheet. Following a bubble to that sheet and comparing the parts it draws against this piece's members needs the sheets themselves, and that is a job of its own — so check_detail_callouts stops at finding the bubbles and reports NOT RUN naming the sheet nobody read. There are three outcomes and only one of them is a pass:

the plan	5.1's detail half
no detail_sheet_prefix declared	NOT RUN — a bubble cannot be told from a part call-out, so the plan cannot even be read for them
a prefix, and the plan cites no detail	OK, and a real verdict — every call-out on the plan names a part directly, and nothing on this piece reaches the model through a detail sheet
a prefix, and the plan cites details	NOT RUN, naming the detail and its sheet — those embeds have not been asked about

5.1 is therefore the first row backed by two checks, and it is answered only when both spoke. CHECKLIST_ITEMS takes a tuple in its check slot and checklist_states makes any quiet half NOT RUN, however green the other one is. That direction is deliberate: a row that asks two questions and prints OK because the half which could still have failed it was never asked is the silent pass this whole table exists to prevent. Under-claiming is the safe direction; a green row is a claim.

What is still not built, stated plainly so nobody reads the above as more than it is: the contents of a detail sheet. Deriving drawings.called_out_on_detail — today a hand-kept job-layer map of which family is drawn on which detail — by actually reading the X-sheets is the same missing capability seen from 5.2's side, and it needs the model.

5.3 reads FOR ENGINEER, not NOT RUN (fixed 2026-08-30)

The owner read a live run and reported "5.3 没跑". It had not run, and it never will — it is one of the two rows this document has counted as a person's job by design since it was written. But it printed NOT RUN, in red, in the same bucket as FAIL, because CHECKLIST_FOR_ENGINEER was a hand-kept tuple holding only 5.5 and nobody added 5.3 to it.

That list is now derived from the table: a row with no check function, no owner finding code, and a reason spelled out is a row somebody declared a person's. A row missing any of the three is an unbuilt row and stays red. The reason string in the row is also what the cell prints, so 5.3 no longer carries a stock sentence about grade D — it is grade C.

5.4 stands down when the design has no mesh, and says which silence it is

Also 2026-08-30, also read as "没跑". 5.4 ran; the design it was checking records no mesh at all (reinforcing.wwf.mesh: null in its extracted spec — its mild reinforcing is a bar line), so there was no design side to compare and the row was right to stay unjudged. The probe's one sentence, however, covered three different situations and sent the reader to Extract Design in all of them, including the one where re-extracting returns the same nothing. It now distinguishes: no spec at all (run Extract Design), a spec with no wwf section (it predates the field — re-run it), and a spec that records no mesh (nothing to re-extract; either the design uses bars, or the summary's mesh line was not parsed, and only the summary view settles which). All three stay NOT RUN.

5.6 / 5.7 say what could not be recognised, not what the piece has not got

Both stand down on the same gather and printed the same paragraph twice, one row under the other, opening with "no reinforcing found on this piece". That is a claim about the piece, and with drawings.reinforcing_families empty the tool is in no position to make it — this plant models bars outside any rebar category, so a piece with three hundred members produced the same words as a piece with no steel in it. The reason now says the tool could not recognise any, says what each row lost (a mark comparison / a length comparison), and names the key that would make it run. When the key is filled in and the search still comes back empty, it says the piece appears to carry none, and names what it looked for. Both rows stay NOT RUN and red either way — naming the switch is not flipping it.

5.5 split into 5.5 and 5.6 — the two lines that matter

What moved to code (5.6): uniqueness. Whether one mark names two parts, whether a printed mark exists in the model, and whether a modelled bar is ever printed are all comparisons between the model's marks and the sheet's text — and a comparison is code's job.

What stayed with eyes (5.5): legibility. Whether the printed glyphs can actually be read is a property of the picture, which no query answers. Grade D, still FOR ENGINEER, and the vision path (ticketvision, AI-BARMARK) is unchanged and still escalates it.

5.6 — bar marks unique, model against print

Three questions, three different defects, each its own WARN under BARMARK-UNIQUE (ticketpage.bar_mark_uniqueness_status):

one mark, two parts	two bars sharing a mark but differing in family or length. The mark is what a fabricator cuts to, so this is the expensive one.
printed, not modelled	the sheet calls out a part the model does not carry.
modelled, never printed	the part exists and the drawing never names it.

A bar carrying no mark at all is none of the three: it is could-not-judge, reported under BARMARK-UNREAD, and is never counted as "never printed" — an absent mark cannot be looked for in the printed text.

The design came from a live read, not from the spec's assumptions, and the read changed it twice.

• The spec said tags. There are no tags. Measured on a bar-carrying WP ticket: zero IndependentTag and zero keynote elements on either sheet. Every printed bar call-out is a plain TextNote on a Detail view. The tag path is still gathered — a plant that tags must not fall through to silence — but nothing here depends on it. One specimen, one plant: worth re-confirming before any tag path is deleted.
• The printed string contains the mark; it never equals it. Verbatim off the sheet: SR324 (F.F.), SR310 (E.L.), P76 W/ SR5602 (S.I.F.) — a bare mark plus a face designation. An equality comparison would have reported every call-out on every ticket as an orphan. The match is a whole-token containment, and the same reduction runs on both sides so an unrecognised shape goes missing from both and produces silence, never a false finding.
• Note-view pollution: real, and separable by view TYPE. The note views are Legends carrying headings and the jacking-force paragraph; the call-outs live on Detail views. Legends are excluded — a view-type test, so no plant nomenclature is needed and none was invented.

Two narrowings, both off the knowledge layers (2026-08-31)

Both landed on one live complaint — "SR4996 是 SP29/30 的附属 rebar，我记得我增加 过这条知识了，为什么还在 WP117 报 warn？" — and he was right twice over. The shape, the merge law and the refusals are in docs/knowledge-override.md; what a reader of the report sees is this.

A bar covered by its parent's callout. SR4996 ships inside the SP29/SP30 angles and is never drawn on its own. That was recorded in three places and 5.6 read none of them, so the "modelled, never printed" leg reported it. It now consults drawings.annotation_covered_by_parent (through knowledge.attached_parents) and produces one of three answers, never a silence:

the parent	the row
is printed	the bar is accounted for, and the coverage is named in the sentence — "SR4996 is attached to SP29/SP30"
is not printed	still a WARN, and now it is about the PARENT. The bar is unaccounted for either way; what is missing is the parent's callout
cannot be read	no claim either way — nothing in the parent's name is shaped like a part number, so whether the ticket calls it out could not be established

A printed token that is not a bar mark at all. 5.6 took every mark-shaped token for a candidate, so WP115 reported P78, P114, SP29, SP30 and SP31 as "printed bar marks matching no bar in the model". They are hardware. A token is now classified through the plant's part-number grammar (part_numbers.prefixes, kind: hardware / kind: bar_mark), and P78 W/ SR5502 (S.I.F.) splits itself — the part is set aside, the bar after W/ still counts.

Three properties hold the honesty, and each is a way this could have gone quiet instead:

• Only kind: hardware removes a token from the comparison, so only it is gated on a verified: true prefix. An unverified hardware claim is refused and the token is reported as unplaceable. kind: bar_mark needs no gate — the worst it can do is add noise.
• A token the grammar cannot place is its own WARN, could-not-judge, never a quiet drop. A printed MK12 says the grammar has a hole and names it.
• A plant that has declared no grammar loses nothing. Nothing is narrowed and every token stays a candidate, exactly as before — noisy, never quiet.

Everything set aside is stated on the row, on a green row and on a red one alike. A narrowing you can only see when everything else passed is a narrowing nobody audits on the runs that matter.

5.7 — no bar longer than the stock it is cut from

Owner's ruling, 2026-08-30: "rebars come in 40ft stock. unless overwritten by other knowledge, all rebars pieces must be less than 40ft." Stock is industry data, not a plant habit, so the number is published in knowledge/catalogue.yaml as catalogue.rebar.stock_length_ft and any higher layer may override it. With the key null the check does not run and says so — it never assumes 40.

The length is READ, never measured. Owner, same day, on a bar's length with bent bars included: "钢筋的长度,即使是弯筋的长度,也都不要自己测量" — never measure it yourself; read the parameter. He named the parameter; the name is written down in the plant layer under the member.length role, which is where a parameter name belongs. The check reads that role and nothing else. There is no geometry fallback and there must never be one: what a bent bar consumes off the stick is its developed length, and a bounding box only sees the envelope it folds into — it understates every bent bar and would pass exactly the pieces this check exists to catch. A bar without the parameter is could-not-judge, named.

Three states, not two. Verified on the live model: the parameter sits on the instance and its internal unit is decimal feet (4.41666… reads as 4'-5"). A length of 0.0 is its own state — 260 elements hold one — and is neither a length nor an absence, so it is neither passed nor flagged.

Grouped by mark, and the reason is arithmetic. The model carries 2,122 elements at or over 40 ft (max exactly 60.00). As one finding per element that is a wall of noise that buries every other row; as one finding per mark it is a short list a person can rule on — and mark is also the grain the owner's ruling will arrive in.

What it does not claim, yet. A bar over stock is not automatically a defect: a continuous or spliced run is a real detail here (the catalogue records x CONT. (SEE PLAN) LAP SPLICE). Whether the 60 ft marks in this model are those is with the owner and has not been answered. So the WARN says the ruling is pending, and the answer when it comes is a list in catalogue.rebar.stock_exempt_marks — a config edit, not a code change. Nothing is pre-exempted, and what is exempted is listed in the report rather than silently dropped. The key is matched exactly, never as a substring, or an entry for SR1 would swallow SR1101.

Two fields carry a bar's size, and they cover disjoint populations

Every bar is measured against the stock length for its own size (catalogue.rebar.stock_by_size, per-size, in integer inches). A bar whose size cannot be resolved is not judged at all — not against the generic number either, because "40 ft" and "40 ft for a #4" are different claims and the generic one is wrong in the direction that passes a defect.

The size is reached two ways, and neither is the other's fallback. Censused over 24,539 rebar members in 13 families, 2026-08-31:

population	field	coverage
the one straight family	the size parameter, parameters.member.bar_size	that family, and no bent one
all twelve bent families	the size at the front of the family's part description, #N BENT BAR (<code>)	100% on the type, instance count zero; 7,405 of 7,405 parse

The two sets are disjoint — no bar carries both — so the order knowledge.bar_size_of() tries them in has never decided anything and must not be read as a ranking. Bent bars are roughly 30% of the reinforcing in this model, and until 2026-08-31 only the straight half was wired: the size role had landed and ticketchecks._bar_size still read that role and nothing else, so every bent bar went unjudged.

Which element the description is read off is load-bearing. An assembly's identity description is the owner's freeform notes; a family's is structured plant data describing the part — one parameter name over two kinds of element. drawings.bar_size_rule.description_read_from is what keeps them apart, and docs/knowledge-override.md records the correction.

The parse stays strict, and not because the field is unreliable: the shape #N BENT BAR is the evidence that the leading token is a bar size, so a reworded description stops being evidence and the bar goes unjudged rather than mis-sized. A leading bare number is refused for the same reason.

The finding says which field answered. BAR-LENGTH-SIZE-BASIS — its own code, owned by no row, so provenance can neither turn 5.7 green nor vanish from the report — names how many bars were sized read from the size field behind parameters.member.bar_size and how many parsed from the part description, with the sizes. A verdict that cannot say what it read cannot be audited. The over-stock line names the size too: "SR1101 at 60 ft vs its 40 ft stock for a #5".

Exempt by mark, not by family — a deliberate departure from how _is_reinforcing identifies a bar. That function asks is this a bar at all, where family is the right grain. This asks may this bar be longer than a stick, which is a property of the part: one family here carries both 11 ft bars and 60 ft ones, so exempting by family would exempt every bar at the plant and switch the check off.

Today it is dormant here, and that is correct. Which members are bars is decided by _is_reinforcing and by nothing else — Revit's own category, plus drawings.reinforcing_families. This plant models its bars as Specialty Equipment, so the category signal says nothing, and the families key is empty. Until it is filled in, 5.6 and 5.7 report NOT RUN naming that key. That is the conservative outcome, and it is also what keeps the length check from opening with 2,122 findings derived from a family list nobody has vetted.

drawings.reinforcing_families is an armed switch — what one edit does

Worth writing down before anyone throws it, because it is not one key and it does not turn on three checks cleanly. Populating it:

• flips 5.6 and 5.7 live. Neither needs a second key. Expect, on the first run over this model, 2,122 mark-grouped bar-length findings and 260 present-but-zero lengths reported as could-not-judge — the population the "zero is its own state" branch was written for, about 11% the size of the ≥40 ft set.
• does not, on its own, flip 5.2's reinforcing half. That half is gated by a second key, drawings.full_length_bar_fraction, which is also null by default and is deliberately not guessed — the standard says "full length bar" and never says how short still counts. With bars newly visible but the fraction unset, bar_drawing_home returns None for every bar, so every bar family lands in unclassified and 5.2 grows a new BED-REVERSE-UNCLASSIFIED line naming them all — and where bars are the only thing left to compare, 5.2 flips from OK to NOT RUN.

So the honest framing is two checks go live, and a third changes behaviour in a way that is neither working nor broken. Throwing both keys together is the edit that actually lands 5.2's reinforcing half; throwing only the first is safe but will visibly change 5.2, and a reader who was told "three checks turn on" would read that change as a regression.

5.1 and 5.2 are worth building: Elevation Top on sheet 1 reads as a flat list (P76 W/ SR5602 (S.I.F.), P106 (S.I.F.)(E.S.), P136 (N.F.) twice, DEBOND STRAND, SP126 (S.I.F.), SR309 (E.L.)) and the assembly's member families are directly comparable to it. Nested children need the SuperComponent filter or the counts double.

6. Handling and lifting

#	check	grade
6.1	Insert capacity vs the load each carries	A
6.2	Insert edge distances	A
6.3	A current handling result exists and passes	A
6.4	Dunnage not landing under an opening	A
6.5	The DUNNAGE / ERECTION / PICKING-STRIPPING notes actually say something	A B (re-graded 2026-08-30)
6.6	An odd count of one part carries the BED PLAN note it requires	B (built 2026-08-31)
6.7	Minimum spacing between lifting anchors	A (built 2026-08-31)
6.8	Printed picking stations match the modelled picking inserts	B (built 2026-08-27)
6.9	Lifting-point count vs panel length (plant rule)	A (built 2026-09-02)
6.10	Lifting-point position vs PCI recommendation (plant rule)	A (built 2026-09-02)
6.11	Dunnage-point count vs stripping-point count (plant rule)	A (built 2026-09-02)
6.13	Lifter accessory (cup/patch) is a member of the assembly	A (built 2026-09-08)

Rows 6.8 - 6.11 were built in the days after this table was last edited and sat unlisted here until 2026-09-08 (issue #26 read the section as ending at 6.7 in the doc and 6.10 in the code; the code and checklist.master in knowledge/catalogue.yaml both run to 6.11). The catalogue is the authority for what exists; this table is the narrative. 6.12 is unused: the FLEXURAL_CHECKS_ALREADY_ASKED comment in ticketchecks.py records that a "6.12" built to an earlier draft of the flexural table would have been 6.10 twice, which is why issue #26's lifter-accessory membership check (a nested cup / patch that fell off its anchor's assembly) is numbered 6.13 rather than reuse it.

6.9 / 6.10 / 6.11 no longer print as NOT RUN on a plant without the gating keys. Until 2026-09-08 a job whose knowledge layer had never declared lifters.lifting_points.two_point_max_length_ft / .two_point_absolute_ max_ft / .pci_position_tolerance_in / .dunnage_matches_stripping (any plant that is not MC) still showed all three rows inline as red NOT RUN -- indistinguishable from a check that failed on a real piece, and read by the owner on another plant's job as "a pile of MC checks." ticketchecks.PLANT_GATE_ KEYS now names, per check, the knowledge key(s) that gate it; when a job has not set them all, ticketqc_run.py pulls the row out of the coloured table entirely and lists it, with the missing key(s), in a folded "Not applicable at this plant" section instead -- not counted in the header's OK/WARN/FAIL/NOT RUN tally. A plant that HAS declared the keys (MC today) still gets the rows in the table, judged exactly as before -- nothing about the arithmetic changed, only which plants are asked to answer it. See ticketchecks.plant_gate_reason / plant_scoped_out.

6.13 is now built (check_lifter_accessory_in_assembly, LIFT-ACCESSORY-NOT-IN-ASSEMBLY / LIFT-ACCESSORY-UNCLASSIFIED), and it reuses the 5.11 gather rather than adding a second reader over the same parts: ticketqc._nested_children_of is the core _read_nested_solid_zones (one recognised family) and the new _read_nested_children (every family) both walk, so GetSubComponentIds() on each recognised lifter is read the one way. Classification is against lifters.accessories in the plant layer (knowledge.lifter_accessories()) -- a child family listed there and absent from the assembly is a FAIL, an un-listed child also absent from the assembly is a separate WARN, and a read failure is never a quiet pass. Live-validated 2026-09-08 through the bridge: WPA648 (assembly 9141343) FAILs naming its 8 DB_PATCH children nested in LPA pin anchors that never joined the assembly (e.g. child 9521037 under anchor 9521036); WPA655 (9141344) and SMD516 (6113164) are OK.

6.7 — a rule that was on a page we already had

ALP catalog p53, 02/2024, in a footnote under the capacity table:

Minimum anchor spacing is 2x the published edge distance

The owner supplied that page. Its edge-distance column became 6.2 and its capacities became catalogue.inserts; this sentence on the same sheet was read past, so until 2026-08-31 nothing in the tool asked how far apart two anchors must sit. Two 8-ton anchors 20 in apart passed every row on the board while the page asked for 28.

It is 6.2's shape one comparison further — the same insert positions, the same per-part resolution through the plant's alias, one more measurement — and it answers LIFT-SPACING.

Where the minimum comes from, in order:

min_spacing_rule.published_in	a sheet stating a spacing outright. Source published. A measured number for the part beats a rule of thumb about it.
multiple_of_edge_distance × the part's own min_edge_distance_in	the p53 footnote. Source derived, and the finding prints the arithmetic — "28" is 2x QLPD8T8WG's published edge distance of 14"" — because "28 inches" and "twice this part's published 14 inches" are different claims and only the second can be checked by a reader.
nothing	could not judge. There is deliberately no plant-wide fallback: doubling a general number would produce a specific-looking claim about a part nobody measured.

Its states, and none of them is a quiet pass:

• a pair too close, both ends resolved from the part's own data → FAIL, naming the gap, the minimum, and where the minimum came from;
• every pair clear → OK, naming what they were held to;
• an insert the catalogue does not cover, or one whose entry publishes no edge distance to double → that pair is not judged and is named in the same finding, on the same code — a second LIFT-SPACING would be dropped by checklist_states, which keeps the last finding per code, and the row would print half the answer;
• nothing judged at all → NOT RUN with the probe's reason, in red. The probe distinguishes three silences: fewer than two inserts with a readable position (a fact about the piece), unreadable geometry (about the read), and no resolvable minimum (about the catalogue).

A mixed pair is held to the larger of the two minimums. A 14 in anchor beside a 6 in one does not get to sit at 12 in: taking the smaller passes exactly the pair the check exists for.

The thickness axis is excluded, for connector_edges' reason and one of its own. Anchors in a lifting wythe all sit at one depth, so the depth term contributes nothing on a normal piece — and where it would contribute, a three-axis distance is larger, which is the direction that passes a pair the page would refuse. The axis is derived (the span closest to the piece's own thickness), never assumed to be an index.

Not yet run against a live model. The host tests cover the arithmetic, the resolution order and all four silences; what nobody has done is press Ticket QC on a real piece and read the row.

6.4 could not say why it said nothing, until 2026-08-30. The check had six silent return [] paths and no skip probe, so run_all logged it RAN-EMPTY and the row rendered NOT RUN with the reason "no probe declared" — a sentence about the tool that told the reader nothing about the piece. Every one of those sites now leaves _dunnage_silence behind and a probe reads it, the same shape 5.2 already used.

Zero openings is a pass, and it is checked FIRST — owner's correction, 2026-08-31, reading a live report: "6.4 应该是 OK, 既然没有 opening". Until this fix the geometry was only ever consulted after the printed dunnage insets had been read off the sheet, so a piece with no opening at all still rendered NOT RUN the moment its size notes failed to parse — the row was complaining about a station that could never have mattered. The check now solves the panel geometry before it ever reads the sheet: if the piece has zero openings, the row is settled on the spot — "no openings on this piece — dunnage cannot sit over one; dunnage stations were not needed" — and the sheet, the notes, and the stations are never touched. The two cases that were never a pass keep behaving exactly as before, now reached only once an opening is actually on the piece: "no size notes found" and "notes found but none parsed into feet" are failures to read the ticket, and a ticket whose dunnage row could not be read is not a ticket whose blocks are clear of the openings. Both keep reporting NOT RUN. Openings present and clear of every station still reach the fall-through pass after the clearance loop — "every one of the N dunnage station(s) is at least 6" clear" — the same reasoning as 4.7's flip, unchanged.

The zero-vs-ungathered line that made the fix safe. liftexport._openings hands back an empty list both for a solid with no opening and for a solid it was never given (its own guard: if solid is None: return []), so "zero openings" and "openings never gathered" are NOT the same signal on that return value alone — collapsing them would have turned a geometry read failure into a false pass. The check now checks solid is None itself, before calling _openings: the panel's extents are already solved by that point (Q.concrete_extents), which walks the same geometry under the same size threshold liftexport.concrete_solid does, so a solid missing on the second read is a real read failure, not a real zero. That case keeps reporting NOT RUN with its own reason and is never presented as a clear piece.

One open judgement call, named rather than decided. When the plant sets opening_counts_only_if_through_thickness and every opening on a piece turns out to be a blind recess, a case can be made that the plant's own rule has answered the question and the row should read OK. It is reported NOT RUN instead, with a reason that says exactly what was found — NOT RUN under-claims, which is the safe direction. This is a different case from the zero-openings fix above: here the piece genuinely has openings, just none of them through-thickness, so it is worth the owner's ruling on its own.

6.5 is new. On the pieces audited, those three note views contain their own titles and nothing else — DUNNAGE, ERECTION, PICKING/STRIPPING. If the content is graphics rather than text this check must look for graphics too, but a heading printed over nothing is a real ticket defect and nobody was looking.

Re-graded A -> B, 2026-08-30, built the same day (NOTE-CONTENT, ticketpage.note_view_content_status). The grade turned on one question that had to be answered rather than assumed: can the API see this at all? It can. A note view's contents are ordinary view-owned elements — FilteredElementCollector(doc, view.Id) returns the text notes (already used by _flat_text for the jacking-force and BED PLAN checks) and everything else drawn there. "Does this view hold anything besides its own heading" is therefore a counting question with an exact answer, not something that needs a picture. No vision path is required and none was built.

B rather than A for one reason: which views are the note views is plant nomenclature. DUNNAGE / ERECTION / PICKING-STRIPPING are this plant's names, they go in notes.instruction_views, and the default is empty — so until a plant names them the row reads NOT RUN with that reason, never a pass. Mechanical rule, local constant: grade B.

Graphics count as content, and that is not defensive padding. A plant that draws its stacking instruction instead of writing it would have every one of these views reported empty by a text-only check — the tool would fail every ticket at the plant it was built to help. So the check counts every view-owned element, and says in its own message when the content it found was graphics, so a reader knows what was and was not read.

What was deliberately not built. A note view holding something passes. A note that is present but stale, wrong, or says nothing useful (N/A, a leftover line, last year's instruction) is not caught, and no amount of element counting will catch it. That residue is a genuinely different kind of check — its verdict would come from a model reading the rendered sheet, which cannot be unit-tested to a fixed answer and may differ run to run. It does not belong anywhere on the A/B/C/D ladder, which grades what it takes to compute an answer; it needs its own category before anything is built for it. Left open on purpose.

6.6 — an odd count of one part demands a note on the BED PLAN

Built 2026-08-31 on the owner's ruling (PARITY-NOTE, ticketpage.parity_note_status / ticketchecks.check_parity_note): when the count of one particular part on a piece is odd, the ticket's BED PLAN must carry a particular phrase. An odd count with no such note is a defect.

Three plant facts, not one rule. Which part is counted, which parity demands the note, and what the note says are three separate things, and every one of them is another plant's to answer differently. So none of the three is in the code: they are drawings.parity_note_rule.family_names, .parity and .require_text, and with any one of them unset the row reads NOT RUN naming the key that is missing. Nothing is guessed and nothing falls back.

The count comes from the MODEL, and the printed BOM would have been a trap. It is one scoped asm.GetMemberIds() pass, the idiom check_bom_members and _bar_members already use. Taking it from the ticket's printed BOM looks like the more faithful reading of "the count on the ticket" and is not: this plant's lifting hardware is among the model extras that never appear on a BOM row at all — check_bom_members says so in its own docstring, and skipping them is why that check works. A BOM-sourced count would therefore be zero on every piece, zero is even, and the rule would never once fire. A check that passes everything silently is worse than no check.

What the BOM would have caught and this does not: a model and a printed bill that disagree about how many of the part there are. That is real, and it is 5.1's question. The call-outs drawn on the plan — what a person counting the ticket by eye actually counts — are 5.2's. Three readings of one number that can disagree with each other is how a tool gets two answers to one question; this row asks only what the piece is and what the plan says.

One unread member flips the parity, so an unrecognised member stands the whole row down. Every other check here can afford to report on what it could read and name what it could not. A parity cannot: a census one member short is not a slightly worse answer, it is the opposite answer half the time. So a member with no readable family name makes the row NOT RUN, naming how many there were and why.

Zero is an answer, and it is not the same answer as silence. A piece carrying none of the part has a count of 0, 0 is even, the rule does not apply, and the row is a genuine OK — it says so in those words, and prints how many members it read, so a family name that matches nothing is visible instead of silently even. A piece whose members could not be identified is could-not-judge and is never a pass. The two arrive at the verdict function as different arguments so that no later edit can collapse them.

The order of the gates is the design. Configuration first, then the census, then the parity, and the BED PLAN last — because a count whose parity does not demand the note is fully judged without ever opening the plan. Demanding a readable plan before that would print NOT RUN for a piece the tool can answer completely. The plan is not even read on those pieces: the check hands the verdict function a reader rather than the text, and it is called after the parity gate or never.

The phrase match is case-insensitive and survives line breaks, because a note typed over two lines is the same note. ticketqc._flat_text already joins a view's text notes with a single space and collapses runs of whitespace; the phrase is normalised by the same function as the text it is looked for in. The printed call-outs are plain TextNotes on the detail views — established when 5.6 was built, and unchanged.

Grade B rather than A, for two reasons that are worth stating. The count rests on a family name the plant declares, not on anything the model says by itself. And a present phrase proves only that the words are on the plan, not that they are about this part: the owner has used the same wording for something else entirely (2026-08-16, on the *.A packets — a piece can need a temporary precast beam that exists for the erection and is removed in the field). The OK says exactly what it saw and claims nothing more.

It ships dormant, and that is the whole safety

drawings.parity_note_rule.family_verified is false until somebody has read the family name off a live document, and while it is false the row reads NOT RUN quoting family_unverified_because. This is the guard reinforcing_rule.parameter_verified already carries, and here it is doing more work than usual: a family name that matches nothing counts zero on every piece, and zero is even. Get the name wrong and the row is a permanent, invisible OK over a whole defect class — the exact failure families.lifter_include had before anyone noticed the plant's inserts are not named LIFT or ANCHOR.

The match is on the whole family name, case-insensitively, and that is a choice between the two shapes already in the tree rather than a third one. families.lifter_include and drawings.reinforcing_families match substrings; drawings.reinforcing_family_overrides matches the whole name, "or an entry for SR1 would swallow SR1101". A part number is exactly that shape of token, and this job's own piece marks are WP<number> — a substring token would swallow the piece named for the same number. A plant whose family name is longer than its part number writes the longer name.

What only a live press can settle: whether the part is modelled under a family name that equals the part number, or under a longer name containing it. The plant layer lists it bare in families.lifter_include, which is substring-matched and so cannot tell the two apart. One read of a family name off a real assembly answers it and flips family_verified.

6.3's handling findings on these twelve were run on default stages with nobody having picked the inserts. That is enough to find a problem and not enough to sign, and the report has to keep saying so.

7. Interference

#	check	grade
7.1	Interference check	B — the tolerance is a plant fact

Nine of the twelve failed. The recurring pair is SR5602 x P136 overlapping 0.21–0.23". A pair that repeats across pieces is one modelling pattern, not nine defects — cluster interference findings by family pair before reporting them, or the count misleads.

The pairs are a FILE, not a note (2026-08-30). A WARN writes every pair to <qc root>/interference-<mark>.csv — beside last-ticketqc.txt, next to the model — with the owner's header MARK,ID,X,MARK,ID and then FAMILY_1, FAMILY_2; the middle X column is the versus between the two sides and holds a literal x. The row's note keeps the count, the population, the depth band and a link to that file, because a 180-character cell truncated the evidence and kept the diagnostics.

THICKNESS_IN and VOLUME_IN3 were dropped from the file (2026-08-30), on the owner's ruling: keep them only if they could ship hidden by default in Excel, otherwise turn them off. A .csv is plain text and carries no column formatting, so a hidden column in one does not exist — both are gone. Thickness was not decoration (it is the quantity the filter tests, so it was the only per-pair answer to why is this pair here), so it survives as a band in the WARN note — shared material 0.13"-0.85", over the 0.125" that flags a pair, deepest row first — and the file's rows stay sorted deepest-first. Volume had no such duty: depth is the question this check asks, and volume never decided anything. Written only when there are pairs; deleted at the start of every run, so a piece that has been fixed cannot keep the file that says it has not. The population is the ticket's OWN assembly (member_boxes → asm.GetMemberIds()) and never the model — the note says so in words, because six numbers in one parenthesis, the first counting elements and the rest counting pairs, read as a whole-model sweep to the owner on WP296 (142 members, then 940).

8. Text hygiene

#	check	grade
8.1	No unresolved lines in the design summary	C
8.2	No invisible or non-printing characters in ticket text	A

8.2 is new and concrete: a U+200E left-to-right mark is sitting in the design summary of these pieces. It is one of the five lines the spec reader could not interpret, and it crashed a tool that tried to print it. Invisible characters in text that a person is expected to read are worth refusing outright.

---

The table itself: nothing is truncated, and a long note folds

Owner, 2026-08-30, having read a live 4.5: "4.5被截断了。我经常在notes里面有截 断。不要有截断，item不要折叠，需要一行就一行，需要两行就两行，但是note做成默认 折叠显示跟item一样的行数。"

What was cutting it was the data layer, not the styling. ticketpage.checklist_states ran every non-OK message through a 180-character capped_note(), so the row tuple itself carried a stump — and the row tuple is what the HTML table, last-ticketqc.txt and every other consumer are built from. 4.5 lost its second debond run mid-number (… 0.958 ft of concrete from 25.875 t…) in the panel and in the file the reader is told to fall back to. NOTE_CAP and capped_note are gone, and a test asserts they stay gone.

What replaced the cap is a fold, and it is height-only:

• The item cell is never folded. One line if it needs one, two if it needs two.
• The note cell collapses to its own row's item height — max-height in em, overflow: hidden, and the whole note inside it. Nothing is removed, so a collapsed note can still be selected and copied in full.
• Every row folds a long note, red included. Until 2026-08-31 a red row (FAIL, NOT RUN) never folded — the reasoning then was that the reader must not have to click to read a problem row. The owner overruled that: "notes太长的话默认折叠" — long notes fold by default, no status named or exempted. Since the original rule shipped, notes got long on purpose (row probes' full multi-clause reasons, shared-silence cross-references, dated mute reasons), overwhelmingly on NOT RUN — the very status that used to be exempt — and he is now looking at walls of text. What still holds: the state colour and the row's own item_lines worth of visible text before any click, on every status; a fold is a clip on height, never a cut on content.
• A file path renders outside the fold, so 7.1's collapsed note still hands over its link — on any status.
• The control says how much is behind it ([+] the whole note (330 characters)), which is the one thing the old … did do.
• The text file has no fold at all — everything, wrapped, as before.

…and the text file carries his own words, in his own script (2026-08-31)

last-ticketqc.txt is documented above as the complete record. A live run wrote it with every CJK character of the job file's mute sentences removed — the ASCII fragments and the gaps between them survived, and the same sentences rendered correctly in the panel and in qc-run.json. A file promised as complete that silently drops half a sentence is worse than one that fails to write.

Two boundaries, both now closed in ticketpage:

• str() on a note. Replaced by _text(), which is vibe.compat.as_text — the project's one answer to this class. Every note, detail line, mute reason and row field goes through it, from the moment the reason is read out of the job file (muted_checks) to the moment it is wrapped.
• textwrap's whitespace step. It munges whitespace by calling text.translate(<a 256-entry table>) on anything it takes for a str. On CPython that table covers every byte; the engine here is IronPython 2.7, whose str holds .NET UTF-16 text, so a character above U+00FF has no entry in the table at all — which is exactly the set of characters that came back missing. _wrap_text flattens the whitespace itself and tells textwrap not to do it again.

The suite cannot reproduce this: the host interpreter it runs on has neither boundary. So there are two tests — one that a non-ASCII note survives (true on any engine, and the promise itself) and one tombstone that pins the shape, because what protects the report here is the absence of two calls.

---

Every row owes a reason — including the rows no check function owns

The guarantee had a hole one level above where it was installed. The skip probe (CLAUDE.md §5) makes a check that returns nothing explain itself, and RAN-EMPTY reports an unexplained silence as the defect it is. All of that is keyed by check function — and seven checklist rows name no check function at all. 1.2, 2.1, 2.3, 3.1, 3.2, 4.1 and 4.2 are answered by finding codes that ticketqc.check_ticket emits directly, so no probe could reach them.

On a live run, 2026-08-31, six of them came back like this:

{"item": "3.1", "state": "NOT RUN", "judged": false,
 "checks": [], "reason": null, "note": null, "owner_codes": ["FC"]}

reason null, note null, and in the text report a bare red NOT RUN with nothing underneath. Eleven codes waited for, not one emitted. The tool gave the reader no sentence to disagree with, and he read the whole page as unnecessary noise — correctly, because a refusal that will not say what it lacks is indistinguishable from one.

And the reasons existed. The design had no extracted spec, so intent.source is regex and every column of the intent table is a dash; 2.1's and 4.1's inputs are a printed size and a printed strand count that did not parse — the same parse failure row 6.4 reports in a full sentence on the same ticket.

What closes it:

• A row probe — the same contract as a skip probe, keyed by checklist row number instead of by function name. It returns why the row would be silent, or None when every input is there. ticketchecks._ROW_PROBES.
• The answer travels in the run log, under row:<number>. The log is the one channel that already reaches every consumer — the button hands it to checklist_states, ticketvision writes it into qc-run.json — so nothing else had to be edited to carry it. (missing.reason in the JSON was not the fix: it is a generic catch and it never reaches the text report at all.)
• A last rung that cannot be empty. With no probe and no declared reason, the row prints a sentence saying exactly that, naming the codes it waited for. Same ruling as RAN-EMPTY's "no probe declared": an unexplained silence is reported, never blanked.
• A mechanical test, so a new code-answered row with neither a probe nor a declared reason fails in the suite rather than on his screen — test_every_code_answered_row_can_explain_its_own_silence, plus one that walks the whole table and asserts no NOT RUN row carries an empty reason.

One fact is said once and then cross-referenced. Rows 4.4 and 4.6 stand down on one sentence, and 3.1 / 3.2 / 2.3 / 4.2 on one missing spec; four red rows carrying one fact read as four problems. Rows whose reason shares its opening clause — everything before the first --, which is how these sentences are built (the shared half, then what this row lost) — now name each other: "the same missing input also left rows 3.1, 3.2, 4.2 quiet: one fact, not 4 separate problems". It adds; each row keeps its own words, because a group summary that replaced them would trade one silence for another.

What is not claimed. A row probe reads the same inputs the emitting code reads, but it is not the emitter, so a future edit could make the two disagree — a row explaining its silence with a reason that is no longer the real one. The guard against that is that a probe must go quiet the moment its input is present, which is pinned by test; a probe inside the emitter would be better, and would mean check_ticket returning a disposition of its own.

The approximation, stated. How many lines the item cell occupies is a rendered measurement — column width and font, neither of which exists when this code runs — so ITEM_CHARS_PER_LINE estimates it from the item's length. Being wrong costs a line of preview, never a character of content. The toggle is the same inline-onclick convention every other fold in this tool uses (foldreport.wtClip, beside wtFold); if the script is dead, a folded note stays visually clipped, which is why a path and the text-file copy stay outside the fold entirely (a red row no longer does — see above, 2026-08-31).

---

The NOT RUN sweep (2026-08-31)

The owner's standing order, verbatim: "qc别再给我出这么多not-run。看看能跑的， 能做的，现在都做了去。" Every NOT RUN cause that could be eliminated without his data and without a ruling from him was eliminated in one pass — and the honesty invariant governs how: a NOT RUN dies by making the check RUN, never by softening a state. Nothing below repaints a row; four things were built and one plant layer was armed.

1. The design-summary vocabulary — which killed a row's silence and seven findings

Row 8.1 reported 7 uninterpreted lines out of 7 on a real insulated piece, and row 5.9 (connector sufficiency) stood down on every press saying "the design states a connector requirement that the summary parser cannot read yet" — because the requirement it needed was one of those seven lines.

ticketpage.parse_summary_line is the grammar. It categorises and does not evaluate: a line it places is a line whose shape is known, and nothing in it decides whether a piece honours anything. Four productions, each drawn from a corpus rather than from the one line that prompted it — (a) the live design summary's 9 distinct unresolved lines, (b) 54 distinct … @ <spacing> O.C. … call-outs over 75 occurrences in the plant-manual extractions, both counted 2026-08-31:

production	shape	corpus
spacing	<product> @<spacing> O.C. <qualifiers>	2 live lines, all 54 manual call-outs
placement	CL <items>[@ <zone>] — centred, optionally in a named wythe	3 live lines
conditional	<requirement> NEEDED WHEN <condition>	1 live line
label	an all-letters heading naming the group below it	1 live line

The first @ wins and everything after it is a qualifier. #3S @ 18" O.C. +(2)@3" EA. END states one field spacing and then an end densification, and the measured piece honours exactly that reading. A reader that took the last @ would report the end pair as the requirement and fail every correct piece.

Three refusals are the load-bearing part. They are what stops the row going green by shrugging:

• A line the grammar cannot place stays an 8.1 finding, verbatim, in the shape it arrived in. REINFORCING PER DESIGN is three capitalised words with no digits — exactly the shape of a heading — and it is a deferral, so the label production carries a word list that refuses it.
• A line placed but not valued is not a line that was read. The corpus writes a non-numeric spacing two ways: @ "S" O.C. (a column of a table printed on the sheet — 7 occurrences) and @ __ O.C. (a literal blank — 1). Both are recognised as spacing requirements carrying spacing_in: None and a reason, and 8.1 names them in a clause of their own.
• A conditional is stated, never evaluated. CL #7 BARS NEEDED WHEN THERE ARE OPENINGS is recorded as a condition with the requirement it qualifies parsed inside it, and 8.1 prints it saying the tool does not evaluate it.

The verbatim record is untouched. spec['unresolved'] on disk is the extractor's own account of what its rules could not place; rewriting it with a later reader's opinion would stop it being evidence. So the grammar runs at report time, over whichever list 8.1 was handed, and 8.1 re-derives the split every press — an intent assembled by hand cannot smuggle a claim past it.

2. Row 5.9 now runs, and its design side is joined through the plant's own alias

The join is the whole trick, and no product name is in the code:

the summary says          HK ST100'S @1'-4" O.C.
the plant declares        connectors.marks holds R82
                          connectors.catalogue_alias.R82: HK Composites (ST100)
so the two join on        ST100

knowledge.connector_spacing_requirement does it, exactly, on a code token — one carrying both a letter and a digit — after the summary's possessive 'S is dropped. Matching on HK, or on any substring, would let ST50 answer for ST100: both are HK Composites and they are not the same part. That is connector_product's exact-match lesson one join along.

Three refusals again, and each has a different repair: the summary states no spacing; it states one and no declared connector is named in it (a bar's pitch read as a connector's is a confident wrong answer, and 5.9 FAILs on a shortfall); it names a connector and the spacing is not a number.

The tolerance, and where it came from. The comparison was `widest > required

• 0.5with the0.5a literal inside the function. It is nowtolerances.connector_spacing_in, passed in, **and a run that cannot resolve one compares nothing** rather than falling back on a constant — a borrowed tolerance is the same class of mistake as a borrowed edge distance, and 5.10 already paid for that lesson. The number itself is honest about its own standing: **it is a tool default and not a plant ruling.** The one calibration that exists needed no tolerance at all — measured 2026-08-31, the connectors sit at exactly 16.0 in across the field against a design stating 1'-4"`, so this allowance has never been exercised. 0.5 in was chosen to sit below the finest spacing the corpus prints (½ in) and above the rounding of a printed dimension, and the finding prints the value and the key it came from, pass as well as fail.

End densification is normal and is never flagged: the comparison is against the widest gap, because the same measured piece carries 9.5 in and 6.5 in pairs at its ends.

3. The seven checks with no skip probe

RAN-EMPTY → "no probe declared" is a whole class of NOT RUN and the worst one: a sentence about the tool, printed in red, on a row that may well be fine. Seven checks could still produce it — re-derived rather than copied from a document (CHECKS minus the keys of _SKIP_PROBES, 37 − 30). All seven now have one, and the class is closed by test, not by prose: test_every_registered_check_has_a_skip_probe walks CHECKS, and two siblings catch a probe keyed by a renamed function and a probe returning '' (falsy, so run_all would read it as "ran and found nothing" — a probe meant to explain a silence turning that silence green).

check	row	what the probe says
check_lifter_capacity	6.1	no insert recognised — and it names both readings: the piece carries none, or none matches families.lifter_include
check_handling_result	6.3	three paths: no panel_id, handling.lifter_groups empty, no mark
check_member_interference	7.1	interference.check is off, or no panel_id — and it goes quiet on the clean path, or a piece with no clashes would read NOT RUN
check_picking_match	6.8	no sheet / no length / no picking families / the printed band did not parse, which is the tool's reading failure and never a defect in the piece
check_sheet_name · check_ticket_set · check_invisible	1.1 · 1.3 · 8.2	these three have no silent path at all

The last three are a second shape of probe and it is deliberate. sheet_name_matches, ticket_set_status and invisible_chars answer with a severity and a sentence for every input, including no sheets at all — a piece with no sheet gets FAIL "no sheet found for this piece", not silence. So their probes return a reason always, saying so: they never fire while the checks behave, and the day a refactor makes one return [] the row names the check and says the silence is a defect in the tool, not a verdict on the piece. That beats "no probe declared" by naming the place to look.

4. The two checks that ran and could reach no row

check_bom_strand_count (BOM-STRAND) and check_picking_match (PICK-STATIONS) had been registered and running with no master entry naming them — so their findings landed in qc-run.json under a code no row owned, and BOM-STRAND can FAIL. They were recorded as a reasoned exemption (ROWLESS_CHECKS) rather than wired, because giving a check a row is a decision about what the report claims and that is the owner's. He made it. They are now master ids 4.8 and 6.8, on the plant board in place (46/46, contiguous, nothing off-board).

Why each got a row of its own rather than joining a neighbour. 4.1 already asks printed strand count vs modelled and 6.5 already asks whether the PICKING note view says anything — so the multi-check idiom (5.1) was the obvious move and it is the wrong one here, for a reason worth writing down:

A row is answered only when every check it names has spoken. 5.1 pairs two checks because they are two halves of one question and half an answer is not an answer. 4.8 and 4.1 are two independent answers to a similar question — a BOM linear-feet row and a printed section call-out, different inputs, different failures, different repairs — and either alone is a real verdict. Hanging 4.8 off 4.1 would have made 4.1 read NOT RUN on every ticket whose BOM could not be read: a row that had a verdict turned red over a silence about a different question. That is the opposite of the order.

ROWLESS_CHECKS stays, empty, and so do its three guards — an allowlist with one test that fails if a check reaches no row and another that fails if a listed check gains one. An empty allowlist under a working pair of guards is what "there are none" looks like; deleting it would delete the mechanism that found these two.

5. Rows 5.13 / 5.14 / 5.15: the gather that was a comment

These three shipped with their arithmetic built and their inputs deliberately un-gathered — read_ticket set no solid_zone_pattern, recess_patterns, recess_regions or legend_patterns, and a comment in ticketqc.py said why: writing a Revit read nobody has run and letting the first live press find out is worse than three rows standing down loudly. The reads have since been taken on the live model, id by id, so ticketqc._read_insulation_hatch now ships the path those measurements exercised. Every call in it is individually guarded and every failure leaves a sentence in insulation_hatch_notes that the three rows print behind their own — a gather that can take Ticket QC down is worse than three rows that stand down.

Three things in it are not incidental:

• The filters are read off the view template, not the view. The override that hatches a solid zone sits on the template; a reader that asked the view would find no filter and report the hatch as un-overridden, on a job whose defect is the override.
• Legend views are excluded from the recess count. A swatch is a picture of a recess. The only four recess regions in the model are swatches, and they sit across two legend views — counting them would make every piece look as though it drew two recesses. The plant layer names the token (LEGEND) rather than a second view name, because the next one will be called something nobody predicted.
• A type-level pattern read is authoritative only under a condition, and the condition is checked every run. A filled region is a Detail Item; a filter selecting that category beats the type, and then the type says what the region would have drawn with rather than what it drew. Measured 2026-08-31: no filter on this template carries the category — a fact about today's template, not a property of Revit. The day one gains it, 5.15 stands down naming the filter instead of quietly comparing the wrong thing.

What each row does now. 5.13 runs and FAILS, id-exact: the zones draw the pattern the template's filter sets and the legend's own swatch for a solid zone is a different pattern element — and the one they wear resolves by element id to the 2-inch-recess swatch, so the finding can say the zones render with the recess's own pattern rather than merely "the wrong hatch". 5.15 runs clean for both recess types. 5.14 stands down honestly, and the sentence is the sharpened one: no recess is drawn on any ticket view, the legend views are excluded on purpose so a zero is a real zero — and this reader has never seen a job that does draw one, so it cannot tell a piece that needs no recess from a piece whose recesses were forgotten, and it claims neither.

One question came off the owner's list with a measurement rather than a ruling: VOID_REVEAL_WIDE is not a modelled recess — 22 instances, all on one piece, zero on any insulated piece, none an assembly member. The drafted-region path is the whole path, insulation.recess.modelled_path_verified is now true with modelled_family settled empty, and 5.14 has stopped printing the "the modelled path was NOT consulted" caveat. A tool that keeps hedging about a closed question is noise on a red row.

What is left, and it is all his

After the sweep, a row can still read NOT RUN five ways, and only the first two are eliminable by anybody but him:

1. a check raised (CHECK-ERROR) — a bug, and it names the check;
2. an input this run could not read — the probe names the ticket key or the gather;
3. a plant fact no layer states — the probe names the key: 1.4 nomenclature.design_number_re, 6.5 notes.instruction_view_sets, 5.6 / 5.7 drawings.reinforcing_rule.scopes;
4. a datasheet nobody has supplied — 5.10 for any connector but ST100 (catalogue.connectors.products.*.min_edge_distance_in), 5.7 the per-size stock table's reader;
5. a ruling he has not given — 5.7's bar-size parameter, 5.14's design side, 5.15's legend-text-vs-type-name size discrepancy.

Three rows are not NOT RUN at all and must not be counted as such: 5.3 and 5.5 are FOR ENGINEER by design (yellow, a person's job, with the reason that makes them so), and 3.3, 5.4 and 1.4 are muted on this job with his own dated sentence — muted still runs, still shows, and a mute can never silence a FAIL.

---

Can this be code?

Most of it, yes — but not as one gate.

Counting the grades: A dominates. Those are comparisons between two values that both exist in the model, and they belong in ticketchecks.CHECKS alongside what is already there.

The B items are the same shape but need a constant that is genuinely local — the dimension tolerance on stemmed pieces, whether a printed strand count is per-piece, which rail the dimension chain starts from, the interference tolerance, the release band. Those belong in the knowledge file, and the audit shows why they cannot be defaulted: a wrong default reads as a missing value and the check quietly does not run.

The C and D items are the residue, and they are not the interesting part. What this audit actually shows is that the failure mode worth engineering against is not "the check is impossible" — it is "the check ran against the wrong input":

• reading one sheet of a two-sheet ticket produced 60 false findings on twelve pieces, and would produce roughly a thousand across the model
• one missing knowledge entry (the legend prefixes) fires a FAIL on all 204 WP tickets
• one root cause fanned out into five distinct codes, so the report's shape suggested five problems

A checklist that a person walks through would not have caught any of those. Code would, and did.

So: build it as code, and let the skill be the thin part. A skill is the right home for the C and D items — the reading-the-drawing judgement, the shortlist triage, deciding whether a repeated interference pair is one problem or nine. It is the wrong home for anything a comparison can settle, because a person walking a checklist has no way to notice that the tool handed them half a ticket.

Before either: fix item 0, and re-run. Every number in this document was measured against a ticket the tool had only half-read.

---

8bis. Checks a model has to look at a picture to make

Ruled by the engineer 2026-08-30, prompted by the residue in 6.5: a note view that does say something may still say the wrong thing -- stale, N/A, last year's instruction. That verdict cannot come from a query. It comes from a model reading the rendered sheet, it cannot be pinned to a fixed answer by a test, and it therefore does not sit anywhere on the A/B/C/D ladder, which grades what it takes to compute an answer.

The ruling: such a check reports NOT RUN, and raises a WARN alongside it.

Not a pass, not a fail, and never silent. NOT RUN says honestly that nothing was computed; the WARN says a human still has to look. The two together are the only combination that does not lie: a pass would claim a verdict nobody reached, a fail would condemn on a guess, and silence would be read as a pass by every person who ever skims the report.

Nothing on this footing has been built. What the report may claim on such a check's behalf is settled by the above and by nothing else -- it may say what it could not judge and that someone should look. It may not paraphrase the content, score it, or imply it was reviewed.

Built 2026-08-30 — vibe.ticketvision, tools/vision_read.py

The escalation path exists. One check uses it: 5.5, bar marks legible and unique — grade D, the row that has always read FOR ENGINEER because there was nothing else it could read. Legibility is a property of the picture, so a picture is the only thing that can answer it.

How a sheet becomes an image, and why the resolution is what it is. It does not. A whole sheet is never rendered, and that is forced by a hard ceiling at the far end: the API downscales any image whose long edge exceeds 1568 px, so the model receives about 1.1 megapixels however large a file is sent. A 34 x 22 in sheet inside that budget is 44 dpi — and no bigger render helps, because the extra pixels are discarded on arrival.

So one placed view is exported (Document.ExportImage, read-only, no transaction) at 1500 px on the long edge, just under the ceiling. The effective resolution then follows from how much paper that view occupies:

effective dpi = 1500 / the view's long side, in inches on the sheet

A 6-inch note view is 250 dpi. A 20-inch bed plan is 75 dpi, and is refused — render_plan returns NOT RUN with the arithmetic in the reason below a 150 dpi floor. That floor is the QNA evidence, not a preference: a text layer returned 1316" for both 13/16" and 1 3/16", a phantom strand position survived four sheets until someone rendered at 450 dpi, and stamps invisible to text search were found only by looking. A render nobody can read is a NOT RUN, never a question.

How a model-read finding is told apart from a computed one, in four independent places, because one of them will eventually be dropped by an edit and the other three still have to hold:

the finding	Finding.source == 'model-read' (everything else defaults to 'computed')
the code	AI-*, a prefix no computed check uses and no CHECKLIST_ITEMS row owns — so a read cannot set, flip or satisfy a computed row
the list	its own, result['model_read'], never merged into findings
the report	its own section, its own table, and a column that says a model looked at a picture; every message opens [read by a model, not computed] and ends NOT a verdict
the JSON	two keys, findings and model_read, each entry carrying source and a boolean computed

Every outcome is a WARN, clear included. A model that looked at one view and saw nothing wrong is a reason for a person to look, not a reason to skip looking — which is exactly the shape 8bis requires, and there is no branch in the code that can emit OK or FAIL.

Cost, and why it is opt-in. Run option vision_escalation, default OFF — the opposite of expensive_geometry, deliberately: geometry spends seconds on a machine nobody bills, a model call spends money and leaves the building. vision_escalation_max_calls (default 25) is a hard per-run bound, enforced on both sides of the file boundary, and an escalation past it reports NOT RUN naming the bound rather than being dropped. A full run over all 1105 sheets would be roughly 1100 calls, about US$5.40, and 1.5–2 hours — about 4,300 input tokens a call (2,200 of skill, 2,000 of image) and ~120 out, at Haiku 4.5's $1/$5 per MTok, so $0.005 a sheet; the wall clock is dominated by the per-view image export, not the model. Which views carry bar marks is plant nomenclature (vision.barmark_views, default empty), so an unconfigured plant gets NOT RUN with that reason and never a pass.

Credentials are read from the environment by the SDK in the CPython child (ANTHROPIC_API_KEY, or an ant auth login profile). No key is in the repo, in a knowledge file, in the request, in the response, or in any log — nothing in either half ever reads one into a variable.

What is not test-pinnable, said plainly. The verdict. The same sheet may come back clear on one run and cannot_tell on the next, and no test asserts otherwise. What is pinned, in test_ticketvision.py: a refusal renders as NOT RUN; a failure to reach the model renders as NOT RUN and never a pass; every outcome carries its provenance; the two kinds never share a list, a table or a key; an AI- code owns no checklist row; annotation never changes a row's status; and the resolution arithmetic refuses a render nobody could read.

What was proposed and left. NOTE-SENSE — 6.5's residue, whether a note that says something says the right something — is defined in the skill and not wired: it needs notes.instruction_views populated to know what to render, and no plant has populated it, so it would report NOT RUN on every ticket today. 5.3 (face designations) and 8.1 (unresolved lines) were considered and not proposed: both need a second source the picture does not carry, so every answer would be cannot_tell by the skill's own rules. The title block, the BOM and the handling dimensions were not proposed either, and that is the one worth stating — every number on them is already read exactly by code, and asking a model to re-read them off a picture would replace an exact answer with a guess. Escalation goes down the ladder, never up it.

9. Deliberately not checked

Recorded so nobody proposes them again as oversights. Each was considered against real tickets and left out on purpose.

Shear-cone overlap between adjacent erection anchors. Two anchors close enough that their breakout cones intersect share concrete, and the pair is worth spreading. On two pieces in the reviewed set the engineer moved a pair from 1'-0" to 1'-6" apart for exactly this reason. It is still not a check: the spacing that matters depends on embedment, edge distance, what the anchor is rated for and what the piece is actually being asked to do, and reasonable engineers argue about it. The verdict was: show the geometry, do not judge it. A tool that fails a ticket over a debatable margin trains people to ignore its failures.

The general form of that decision is worth keeping: a check needs a criterion that is not in dispute. Where the criterion is a judgement call, the honest product is a number on the page, not a verdict.

What the review measured

The twelve tickets were audited, then reviewed by hand, and four were corrected. This document's items caught one of the four:

piece	corrected	caught here	why not
WP199	dunnage 4'-9"/4'-9" → 3'-0"/5'-0"	yes	support sat 2.5 ft inside an opening
WP213	dunnage 4'-7"/4'-7" → 4'-0"/5'-0"	no	support sat 5 inches from the opening edge — outside it, so a containment test passed
WP219	3'-3"/1'-0" → 2'-9"/1'-6"	no	anchor spacing, deliberately not checked (§9)
WP220	3'-3"/1'-0" → 2'-9"/1'-6"	no	same

WP213 is the one to learn from. The check ran, returned, and said the ticket was fine — and by its own definition it was right. A criterion looser than reality is more dangerous than a missing check, because a missing check leaves an obvious hole and a loose one produces a clean report.

The criterion, after the fix

Dunnage against openings is now a clearance test: the distance from each support to the nearest opening edge, with the thresholds in the plant file (handling.dunnage.opening_clearance_fail_in / _warn_in, 3 in and 6 in here). Inside an opening stays a fail on its own.

Re-run against the same geometry, both versions of both tickets:

piece	version	far support	clearance	verdict
WP199	before	18.17	inside OPENING 1	FAIL
WP199	after	19.92	11.5 in	OK
WP213	before	17.38	5.0 in	WARN
WP213	after	17.96	8.0 in	OK

Two of two in-scope corrections, where it had been one of two. The other two the engineer made are anchor spacing, which §9 leaves alone on purpose.

The part worth noticing is that the two thresholds were given as plain numbers by the engineer, before any of this was run, and they land exactly on the line he had already drawn by hand: the piece he treated as a defect comes back FAIL, the piece he merely improved comes back WARN. Nothing was tuned to make that happen. When a threshold reproduces a judgement nobody encoded, that is the evidence the threshold is real — and it is also the reason to leave it in the plant file rather than in the code, because it is his number, not the tool's.

---

What is left for a person, counted

The point of grading each item A to D was to find out how much of this a program can do. With the A and B items written, the report renders 29 rows per ticket (27 before 1.4 and 6.5 landed on 2026-08-30) and they fall out like this:

	rows
covered by code	22	OK / WARN / FAIL / FOR ENGINEER, all produced by a check that ran
code not written yet	0	was 1.1, 5.4, 6.5, 8.2. All four are now written; 1.4, which this tally never listed, is written too (2026-08-30)
missing an input	1	3.3 — the spec carries no f'c/f'ci to compare against
a person's job by design	2	5.3 narrows to a shortlist, 5.5 is reading the drawing

Amended 2026-08-30, second pass. CHECKLIST_ITEMS now carries 31 rows, not 29: 2.4 and 4.5 were rows-without-checks when that count was written, and both are now built (CAST-EXTRA, STRAND-CALLOUT), so "covered by code" is 24. The residue is unchanged — 3.3 still lacks its input, 5.3 and 5.5 are still a person's job — and no row has moved into the residue. The column arithmetic above never summed to the row count and still does not; it was not re-derived here, because doing that honestly means re-running the report, not editing a table.

Not one row needs a model to look at a picture. The four unwritten ones are code nobody has typed; the missing input is data, not judgement; and the last two are work that should stay with a person — a tool that took them over would be pretending to a competence it does not have.

That answers a question that had been open on cost grounds: whether the drawing-reading part should move to a local model on the shop's own hardware. It should not, because after the A and B items landed there is no drawing-reading part left to move.

Amended 2026-08-30. That still holds for every row as written, and 6.5 — the item most likely to have needed a picture — turned out not to: a note view's contents are queryable elements, so emptiness is counted, not seen. But building it exposed a residue the ladder has no rung for: whether a note that does say something says the right thing. A verdict from a model reading the rendered sheet is not grade A however valuable it is, because it cannot be pinned to a fixed answer by a test. Before any such check is built, it needs a category of its own and a rule about what a report may claim on its behalf. Nothing has been built on that path.

The reason the question became answerable is worth more than the answer. While the report was a list of findings, "how much is left for a person" could only be estimated, because an item nobody checked produced no line and looked exactly like an item that passed. Once every item occupied a row — including the ones marked NOT RUN, with the reason — the question became arithmetic.

A system that cannot say what it did not do cannot be measured.

---

A row can also be not a question about this piece (2026-08-31)

Everything above grades a row by who answers it. This section is about a different axis the ladder has no rung for: whether the question applies at all — and the answer to that is plant knowledge, conditioned on what the piece is, not a property of the row.

Owner, 2026-08-31, reading insulated panels: "ticketqc 检查的内容需要进行分级。 根据 plant 和 ticket 的具体内容进行分级 ... 让 ticketqc 工具读取厂知识来得知啥需要 检查，啥不用检查。" The mechanism is checks.not_applicable / checks.only_applies_to; the shape, the merge law, the classifier and the worked non-examples are in docs/knowledge-override.md. What belongs here is what a reader of the report sees.

The five states, and the colour each one is printed in

Colours are pinned by tests. A new state gets its own entry, never a reuse of an existing one.

state	colour	did the check run?	what it means
OK	green	yes	judged, and it is fine
WARN / FOR ENGINEER	yellow	yes / by design not	a person must look
FAIL	red	yes	the piece is wrong
NOT RUN	red, exactly like FAIL	no	nobody checked. An unrun check tells you nothing about the piece, so it is never quieter than a failure
MUTED	grey	yes	it ran, and this job asked for it quietly. The note says what it really reported, and a FAIL is never muted
NOT APPLICABLE	blue	no — not at all	a knowledge layer declares this question is not about this kind of piece

Blue is calm on purpose, and calm is only safe because the declaration is loud elsewhere: every run prints, per piece, which profile ran —

PNL101 classified as insulated — 3 row(s) declared not applicable: 3.3, 5.4, 6.6

— and then every switched-off row with its reason, its date, its declarer and the layer that declared it. That section opens itself whenever anything was switched off, unlike the muted section, which folds when it is tidy. A mute leaves the check running; this stops it, and a mistaken rule here is a safety check disabled in silence.

Reading a blue row

• The check did not run. There is no verdict behind the row and there is not meant to be — which is exactly what separates it from grey.
• judged is false in qc-run.json, the same as NOT RUN. The difference between them is why nobody asked, and that is the state word and the reason, never a truth value.
• A row that FAILED is never blue. The declaration is recorded as DECLINED and the row keeps its red — the same ruling as a mute over a failure. This is not theoretical: 4.4 and 4.6 both name check_strand_layout, so a check kept alive for the row that still applies can put a finding on the row that does not.

Reading a red row that a scoped declaration produced

A row declared with only_applies_to exists only for one kind of piece. On a piece nothing could classify it reads NOT RUN, in red, saying so — never OK and never blue. Running it would answer an insulated question about a piece that may not be one; calling it not applicable would claim the piece is not that type, which is precisely what could not be established. It is cured by making the classification work, not by a ruling.

The boundary a plant may not cross

A plant declares applicability over the rows in this document. It cannot define a new one. A new question is a code change, and the reason is the ladder at the top of this file: a row is a claim the tool makes, and a claim needs a check, a skip probe, a grade and a test — the things that let it be wrong in a reviewable way. A YAML-defined row would have a number, a sentence, and no way to fail. That is a checklist row that always looks fine.

What is seeded today: nothing

Both tables ship empty, and a test pins that. The first evidence run (2026-08-31, four live presses on insulated pieces) found no row whose noise was applicability — the "nearly useless on insulated panels" wall was already gone, and it went by running Extract Design and by the face-lifter knowledge fix, not by switching anything off. Of the remaining non-OK rows, four trace to known bugs (a weight sum that misses a wythe on 16" insulated bodies, an 8.1 parser with no vocabulary for TOP WYTHE, a 5.6 parser reading hardware part numbers as bar marks), and declaring any of those inapplicable would bury a real defect under a legitimate-looking declaration.

The first genuine insulated-only question arrived the same day and from the owner, not from the noise: every lifter on an insulated panel must have a solid zone through the insulation. On a solid panel that question is meaningless. It is the worked example of only_applies_to and it is not built — the population is still being measured and what it would compare is undetermined.

---

The checklist is now data, and a plant numbers its own (2026-08-31)

Everything above describes the questions. Where they live, and what the numbers on a report mean, changed on 2026-08-31 — the mechanism, the merge law and the reference grammar are in docs/knowledge-override.md; what a reader of the report needs is here.

Three layers

layer	owns
public (checklist.master in knowledge/catalogue.yaml)	what the questions are — id, wording, grade, owner codes, which check answers it
plant (checklists.profiles)	which of them this plant asks of which kind of member, in what order, under what numbers
job (checks.muted)	the mute buttons

The check functions stay code. A row is a claim the tool makes, and a claim needs something that can be wrong in a reviewable way — a probe, a code, a grade, a test. So what exists is publishable knowledge; what answers it is code, and a new question is still a code change.

Two numbers on every row, and which is which

• the master id is the identity. It never changes. Every mute, every applicability rule and every ruling names it, and a bare number in any document written before 2026-08-31 is a master id and still means exactly what it meant.
• the display number is what this plant's board calls it.

On the page, the master id prints small under the plant's number and only when the two differ — a plant that has not renumbered sees one number, not the same number twice. In last-ticketqc.txt it is always spelled out (2.1 [3.3]), because the file is the fallback a reader is told to trust and it has no hover text. In qc-run.json (now qc-run/3) every row carries item/master_id and display_number, plus renumbered so a consumer never has to work out which it is holding.

A citation that needs to be unambiguous is qualified: sample_plant-wall_panel 3.3.

The report header says which board ran

PNL101 — sample_plant checklist Wall panel (profile wall_panel, chosen on member kind) · member kind: wall_panel

and beside it the classification line. A renumbered table with neither has shown the reader a checklist without telling him whose. The member kind comes from the mark prefix; a piece whose prefix nobody has declared gets no profile and the full master checklist — more questions, not fewer.

If the board does not name a question that exists in the code, it is asked anyway and the header says so. A board is a snapshot of what existed when somebody wrote it; the alternative would let the next check anybody builds run nowhere.

---

5.8 / 5.9 / 5.10 — connectors on an insulated panel

Added 2026-08-31: "insulated panel 加一个 check，检查 connector 是不是存在， 以及够不够", and "再增加 connector edge distance 的 check".

A connector crosses the insulation of a sandwich panel and ties the two concrete wythes together. All three rows are insulated-only.

5.8	connectors present	zero is a FAIL, not a WARN — untied wythes are a structural condition. It is only ever reached after the recognition gate has confirmed the tool can see connectors at all, so a zero here is a zero in the piece.
5.9	enough of them	compares against what the design calls for. Stands down today: the summary line HK ST100'S @1'-4" O.C. is one 8.1 cannot parse.
5.10	edge distances	product-first minimum; a plant-wide fallback is named as such in the finding.

What each says when it cannot answer, because none of them may go quiet:

• recognition unverified → all three stand down with the plant's own reason (one gate, three rows, never three copies of it);
• on a solid panel → NOT APPLICABLE, blue: there is no insulation for a connector to cross, so the question is meaningless rather than quiet;
• on a piece nothing could classify → NOT RUN, red. Calling it not applicable would claim the piece is not insulated, which is exactly what could not be established;
• no published minimum for 5.10 → stands down naming the missing datum, and never borrows another product's number;
• no readable requirement for 5.9 → stands down naming the count it did not judge. A count on its own is a number, not a judgement.

Today all three read NOT RUN on every piece, because panel_types.detect_verified is false — the connector recognition is measured and verified, but the panel-type classifier has never been run against the model. One press confirming it arms all three.

Two calibrations worth keeping, both measured 2026-08-31 on one insulated piece: the field spacing is 16.0 in, which is the design's 1'-4" — and the tighter 9.5/6.5 pairs at the ends are normal, so the comparison is against the widest gap. And the smallest in-plane edge distance actually built is 6.0 in, on work the owner has not questioned — so a published minimum above 6 is a finding to surface, not a reason to set the limit at 6.

---

5.11 – 5.15 — solid zones and insulation recesses (2026-08-31)

Added on the owner's second asking, which is the first thing worth recording:

"没有 solid zone 相关的检查。lifter 自带 solid zone，没检查这些 solid zone 是不是被加入了 assembly，是不是被显示在 ticket 上面，hatch pattern 对不对。 这些都没有啊"

"不光是 solid zone，insulation recess 也得加上。你看看 page 2 里面的那些 hatch pattern 就知道了。"

A solid zone is a block of concrete that replaces the insulation locally so a lifting insert has solid material to pull against. On this job every lifter nests one inside its own family. A recess is a partial-depth pocket in the insulation, and on this job it is not a model element at all — it is a drafted filled region on the ticket. All five rows are insulated-only, through checks.only_applies_to in the plant layer.

The measurements everything below rests on

All bridge-verified 2026-08-31, over the 27 insulated pieces:

nested zones	192 of 192 lifters nest exactly one, via GetSubComponentIds()
standalone zones	82 more, at the openings, nested in nothing
assembly members	21 of 192. 17 of the 27 pieces have zero
rendered on a ticket	0 of 192. The layout view shows only the standalone ones
the live hatch defect	the SOLID ZONE view filter on the insulation view template overrides the surface foreground pattern to TRIANG — the recess pattern

Why this is five rows and not one

They are five different failures with five different repairs, and a single row would tell a modeler something is wrong without telling him what to do.

5.11	the zone is modelled but left out of the assembly	add it to the assembly
5.12	it is out of the assembly, so it never reaches the layout view	the same repair — which is exactly why the row says so
5.13	it is drawn, with the wrong hatch	fix the view filter
5.14	a recess the design calls for is not drawn	draw it
5.15	a recess is drawn with the wrong hatch	fix the region type

5.11 and 5.12 share a repair and are still two rows, because they do not share a cause: a zone can be an assembly member and still fail to render the day somebody changes the view. Merging them would make the second failure invisible for as long as the first one holds.

And 5.12 is not enough on its own. Nested and standalone zones share one type, so making the nested ones visible without fixing the filter would put eight more wrongly-hatched zones on every piece rather than none. That is why 5.13 exists as a row rather than as a footnote on 5.12.

The reference for a hatch is the legend's own swatch

Not a table in a YAML file. The legend printed on the sheet is the sheet's own statement of what each hatch means, and it is the only reference that updates itself when the plant redraws a swatch. So expected_hatch_pattern resolves the legend first and the plant's insulation.legend.expected_patterns second — and every finding says which it used, because "the legend on this ticket says ANSI35" and "a YAML file written on 2026-08-31 says ANSI35" are different claims and only the first can be trusted next year.

The plant map disagrees with the manufacturer's manual on two entries, and that is recorded rather than resolved: the manual (p706 / 8207.2, already in face_designations.insulation_hatch) says HONEY for a 3in recess where this legend draws TUCKPOINT, and calls STARS a 1in cap where this legend labels it 2in. The checks are held to the legend printed on the ticket, because that is what the shop reads. Which of the two governs is the owner's ruling.

What 5.14 does not claim, and why the row exists anyway

There is no model counterpart to compare a drafted region against, and nothing parses the design side — no line anybody has taught a reader to turn into "this piece should have two 2in recesses". So 5.14 stands down today: it prints the inventory it found, states that nothing was compared, and names both unblockers (a design-summary reader, or a ruling that the recesses are modelled after all).

A presence count printed as agreement would be the alternative, and it would be a green row over a question nobody asked. The row is still worth having under this architecture's own reasoning: the inventory is real and written down, the unblocker is in the sentence a reader actually sees, and the day either half arrives the comparison is already written — recess_presence_status takes the requirement argument today and simply has not been given one.

One candidate complication, asked and unresolved. VOID_REVEAL_WIDE (MC='VOID REVEAL') might be a modelled recess. The drafted-region path is built; the modelled path is a named dormant slot (insulation.recess.modelled_path_verified: false) and 5.14's own finding says the modelled path was not consulted. Naming it rather than leaving it implicit is what makes turning it on a YAML edit.

The size question 5.15 refuses to answer

The legend's text says 1" and 2"; the region type names say 2in and 3in. Both are on the same sheet. 5.15 compares patterns, which have an exact answer, and carries a sentence saying the size discrepancy is the owner's question and that he has been asked. A row that quietly picked a side would launder a question into a verdict.

What each row does when it cannot answer

None of the five may go quiet, and every empty return leaves a sentence a skip probe reads — the shape 6.4 had to be retrofitted with, built in from the first commit here.

• the solid-zone family unset, or set and unverified → all three solid-zone rows stand down with the plant's own reason. This is the 6.6 guard and it is doing more work than usual: a family name that matches nothing counts zero zones on every piece, and zero zones reads as "no lifter is missing one" — a permanent invisible pass over the whole defect class the owner just commissioned.
• no lifter recognised → nothing to look inside; the existing connector/lifter recognition is reused and no fifth recogniser was built.
• no sheet issued → NOT RUN, "no sheet issued", and it is neither a pass nor a failure. 12 of the 27 insulated pieces have no sheet yet.
• the layout view unnamed at this plant → stands down naming drawings.insulation_layout, which is landed beside drawings.bed_plan for exactly the reason that key exists.
• no legend read and no plant map → the reference itself is missing, and it is named rather than filled in. No neighbouring concept's pattern is ever borrowed — one concept drawn with another's hatch is the whole defect.
• the rendered pattern not gathered → a named silence, never a pass.

Zero and ungathered never merge. solid_zones reaches the check as [] when the gather ran and found none, and as None when it never ran, and the two produce different sentences. That is 6.4's lesson, landed the same day and built in here rather than retrofitted.

The gather half, and what is dormant

5.11 and 5.12 run today. The gather is GetSubComponentIds() on each recognised lifter plus AssemblyInstanceId against the assembly — the exact reference the measurements were taken with, in ticketqc.read_ticket. Membership is also how 5.12 answers: the layout view is assembly-scoped, so a member reaches it and a non-member cannot. That relationship is an inference, not a rendered-geometry read, and 5.12's finding says so in its own words — because the repair follows from the basis, not from the verdict.

5.13, 5.14 and 5.15 are dormant and loud. Four keys are not gathered, and ticketqc.py carries a block naming exactly what each one costs to fill: recess_regions (a view-scoped FilledRegion collector), recess_patterns (FilledRegionType.ForegroundPatternId, then any view filter, because reading only the type would report every pattern correct on a job whose defect is precisely a filter override), solid_zone_pattern (View.GetFilterOverrides(...).SurfaceForegroundPatternId, resolved against the view template), and legend_patterns (the legend view's own swatches). None of those API paths has been run against a live document, and guessing an enum or a property name is how Revit dies without an exception. One bridge session lands all four.

And the edge that 5.10 measures to changed the same day

"pin edge distance = 3". ST100 的知识。写。检测 edge 检测的不是 concrete edge，而是 insulation edge，所以如果 insulation 有 solid zone 被 cut through 而不只是 recess 的话，那么 edge 就是被 cut 之后的 edge。如果只是 recess，则按照原来的 edge 来算。"

Two things landed, and the second is the larger one.

The number. HK Composites (ST100).min_edge_distance_in: 3.0, source stated by the owner. ST50 and the rest stay null with their reason: he gave one product's number, and borrowing it across designations is exactly what that reason field forbids.

The semantics. The edge is the insulation edge, not the concrete one. A solid zone that cuts through the insulation redefines it — concrete has replaced the insulation, so the zone's border is an insulation edge. A recess does not: insulation still runs underneath, and the original boundary governs. So 5.10's reference geometry is the insulation extent minus the through-cut solid zones, which means it consumes the very population 5.11–5.13 recognise. One recognition, several consumers — a second reader for the same parts is how two rows come to disagree about what is on a piece.

Through-cut versus partial is an inference from names, and it is labelled one everywhere. Depth is not a field; it is text in the type's description (3" SOLID ZONE, 4" SOLID ZONE) beside an insulation type named for its own thickness. Equal depths read as through-cut. A zone whose depth cannot be parsed stands the pins near it down rather than defaulting either way — False would quietly measure to the old edge, which is the permissive direction, and True would invent an edge that may not exist.

The 6.0 in calibration has been withdrawn, and withdrawing it is the point. It was measured pin-to-panel-edge, and he has just defined the measurement as pin-to-insulation-edge. Those are different measurements of different things, and carrying the number across would have set an expectation that the first live run then looked like a regression against. The insulation-edge distances on this job are unmeasured; whatever the first run prints is new information.