# Twelve WP1 tickets, checked against the ticket itself WP194, 195, 196, 199, 200, 210, 213, 214, 215, 219, 220, 412 — all design WP1. Checked 2026-08-27 against the live model and against the twelve exported PDFs. The instruction was to run every configuration from what the ticket prints rather than from defaults. The ticket does carry all of it. This document is mid-revision: the machine-read pass produced several conclusions that looking at the rendered page then overturned, and those are marked RETRACTED rather than deleted, because the way they went wrong is the most useful thing here. ## This audit describes a set that has since been superseded **These twelve tickets were checked before their review, and four of them were then corrected.** The set read here is the pre-review one; a corrected set now exists alongside it. This is not a warning that tickets and models drift in general -- in normal use they agree, and no standing cross-check is wanted. It happened here only because the audit ran while the review was still in progress: the corrections reached the model first and the exported pages had not caught up. What that means for a reader: a figure quoted from this document describes the ticket as it stood before review. Two of the four corrections were to dunnage, both turning a symmetric pair into an asymmetric one: WP199 4'-9" / 4'-9" -> 3'-0" / 5'-0" caught here as HANDLE-DUNNAGE-OPENING WP213 4'-7" / 4'-7" -> 4'-0" / 5'-0" NOT caught here WP219 3'-3" / 1'-0" -> 2'-9" / 1'-6" NOT caught here WP220 3'-3" / 1'-0" -> 2'-9" / 1'-6" NOT caught here **One of four.** The three misses are the useful part, and section 5 keeps the reason: for WP219 and WP220 nothing usable was extracted at all, and an item with no data behind it produced no finding rather than a loud one. A check that cannot see its input has not passed; it has not run. --- ## 1. RETRACTED — the ticket does print the handling positions An earlier version of this document said the three handling notes print no dimensions. **That was wrong, and the error was mine.** The finding came from a text extraction of the PDF content streams; it missed those dimensions, and I reported the absence as fact instead of as a limit of the tool that produced it. Rendering WP210 and looking at it shows the notes fully dimensioned: | note | printed on WP210 | | --- | --- | | PICKING/STRIPPING | `2'-6"` `7'-6"` … `7'-6"` `2'-6"` — four pick points | | ERECTION | `1'-8"` — one point | | DUNNAGE | `5'-2"` and `5'-2"` | The `U+200E` overrides on those dimensions are real — they are in the model — but they clearly do not blank the printed value. What they do instead is not established, and no conclusion should be drawn from them until someone looks. **Method note, which is the durable lesson here:** reading a drawing's text stream is not reading the drawing. Everything in this document that came from text extraction alone is suspect; everything that came from the rendered page is what a person would see. Render and look. ## 2. What the ticket carries, read off the page WP210, both sheets: - **Title block** — MARK WP210, LENGTH 24'-11", WIDTH 8'-5", THICKNESS 8", WEIGHT 20,950 lbs, CONCRETE f'ci 3500 / f'c 6000, QUANTITY 1, PRODUCT CODE 120008, BASE MIX 5.17 CY, FACE MIX 0.00 CY, PAGE 1 OF 2. - **A bill of materials on sheet 1** — QTY / MARK / DESCRIPTION, twelve rows: P106 x5, P114 x2, SP29 x1, SP30 x1, P76 x4 (erection anchor, 8 ton), P136 x8 (4T x 4 9/16" disk anchor, QLPD4T5WG), SR393 x36, SR394 x4, SR538 x2, SR4156 x8, SR4996 x4, SR5602 x4, and 249 of 0010001 (1/2" 270ksi low lax strand). - **Strand count per piece**, in section A-A: `(10) 0010001 (E.L.)`, with the transverse chain 1'-1" / 2'-0" / 1'-7" / 2'-4" and the depths 1 3/4", 4 1/2". - **Bar spacing**, in section B-B: SR393 `(15) @ 1'-6" = 22'-6"`, and chains for SR4156 and SR394. - **Jacking force**: `0.70 fpu = 28.9 kips`. - Two production notes: the chamfer rule and the post-pour threaded-embed check. **This is where the reinforcing schedule lives.** The `LGD-MISSING` check looks for a placed view named `STRAND PATTERN…` or `REINFORCING PATTERN…` and there is none anywhere in the model — but the information it is looking for is on the ticket, as a BOM table and as counts inside the section views. ## 2b. The strand-count finding was also wrong `STR-QTY` reported "summary prints 14 strands but 10 are modelled" on WP210. The ticket itself prints **(10)**, and the model has 10. The 14 comes from the WP1 design summary, which covers a family of pieces. So the 14 is a design maximum and not this piece's count, and `legend.printed_strand_count_is_per_piece` should be **False** for this plant. The same reasoning applies to the other four pieces flagged; each needs its own ticket read to confirm. ## 3. Real failures **Interference — 9 of 12 fail, but it is one pattern, not nine problems.** | piece | count | recurring pair | | --- | --- | --- | | WP194 | 6 | SR5602 x P136 | | WP196 | 5 | SR5602 x P136 | | WP199 | 6 | (pair not named in the message) | | WP200 | 4 | SR5602 x P136 | | WP213 | 4 | (not named) | | WP214 | 3 | SR5602 x P136 | | WP215 | 4 | (not named) | | WP195 | 2 | SR5602 x P136 | | WP219 | 1 | SR5602 x P136 | `SR5602 x P136` accounts for 11 of the named pairs, overlapping 0.21–0.23". SR5602 is a nested child of the P76 embed. One family pair repeating across nine pieces is a modelling pattern to fix once. **Strand count — 5 of 12 disagree with the DESIGN SUMMARY, not with their own ticket.** See 2b: on WP210 the ticket prints (10) and the model has 10. Listed here only so each can be confirmed against its own page. | piece | printed | modelled | | --- | --- | --- | | WP200 | 14 | 6 | | WP214 | 14 | 6 | | WP210 | 14 | 10 | | WP219 | 14 | 10 | | WP220 | 14 | 10 | **Handling — provisional, because the ticket gave nothing to run from.** These ran on default stages with nobody having picked the inserts: - `HANDLE-ASPECT` on WP199, WP213, WP215 (all three stages each) — short/long 0.52, two-way action starting to matter. - `HANDLE-INSERT` on WP215 erection, twice — P136 at 2.25 ft, line force 7,835 lb. - `HANDLE-DUNNAGE-OPENING` on WP199 transportation — dunnage at 18.10 ft lands inside a full-depth opening. Note this used the *default* 0.21L inset, not the ticket's 2'-6"; with 2'-6" it may or may not clear, and the ticket does not print it. ## 4. Failures that are not real 60 of the findings across the twelve are artefacts: **All sixty come from ONE cause, not two.** An earlier version of this section attributed forty-eight of them to reading one sheet of a two-sheet ticket. That was wrong, and it was measured wrong: the multi-sheet union was implemented, and the four codes did not move. - `LGD-MISSING` x12 — no WP sheet in this model carries a pattern-legend view. 0 of 204. The strand count lives inside `Elevation Right` (`(14) 0010001 (E.L.)`); the jacking force lives in a note view; the schedule is the BOM table. The check's premise does not hold for this plant. - `FC`, `FCI`, `PCF-NOTE`, `STR-NOTE` x12 each — **all four downstream of that same missing legend.** `read_ticket` sets `legend_text` only when a pattern-legend view is found: if len(t['legends']) == 1: t['legend_text'] = _flat_text(doc, legend.Id) With no legend view anywhere, `legend_text` stays `None`, `parse_concrete(None)` returns nothing, and each comparison reports "in the summary, not found on the ticket". Which sheet the tool read was never the issue. Verified after the union landed: WP199, WP210 and WP412 each resolve to both `1 OF 2` and `2 OF 2`, `read_ticket` reports two sheets, and all four codes still fire — `legends_found: 0`, `legend_text_is_none: true`. The multi-sheet union is still correct and still needed — a ticket **is** two sheets, and the title block, the BOM and the sections are split across them. It just does not fix these four. ## 5. Also found - A `U+200E` sits in the design summary text as well, and is one of the five lines the spec reader could not interpret. It also crashed a tool that tried to print it. - `TICKET NOTE - WP2- STRAND JACKING FORCE` is placed on 100 WP1 sheets. The *content* is WP1's own number, so the note is right and the name is a leftover. Report the name; do not infer the content is wrong. ## 6. What I need from you 1. **Confirm the reading convention for the three handling notes.** On WP210 the ticket gives picking as `2'-6"` `7'-6"` … `7'-6"` `2'-6"` (four points), erection as a single `1'-8"`, dunnage as `5'-2"` and `5'-2"`. I can read the numbers; what I cannot read off the page is what each is measured from, and for erection, what a single dimension places. 2. **The `U+200E` overrides.** They are on those dimensions in the model and they plainly do not blank the print. Are they a deliberate formatting device, or leftovers? If leftovers, they are worth clearing — an invisible character in a dimension override is a trap for anything that reads the model instead of the page, which is what every check does. 3. **`printed_strand_count_is_per_piece` should be False** on the evidence of WP210, where the ticket prints (10) and the design summary says 14. Confirm, and I will set it and re-run — that removes the five STR-QTY findings. 4. **What is the real interference acceptance?** The check flags shared material over 0.125". SR5602 into P136 at 0.21–0.23" on nine pieces, where SR5602 is a nested child of the P76 embed. Modelling artefact of the nesting, or real? 5. **The BOM table is the schedule** — confirm, and the `LGD-MISSING` check gets repointed at it instead of at a legend view that does not exist here. ## 7. Limits of this audit - The text extraction decoded nothing usable from WP215, WP219, WP220 and WP412 — 14 to 174 garbage characters against 2,641 for WP194. That limit is now moot: rendering works on all of them. - The handling results are default-stage runs. They are enough to find a problem and not enough to sign. - Only WP210 has been read from the rendered page. The other eleven were read by text extraction, which is now known to miss dimensions. **Their findings stand only until each is rendered and looked at.** - The handling numbers above are WP210's. The earlier text pass reported 2'-6" dunnage on WP194 and WP199 from the model rather than the page; whether those agree with their own printed tickets is not yet checked.