will
8e6ee31596
ci / test (push) Successful in 6m18s
History-free snapshot of the private development repository at cbe45c5 (2026-09-09). Code, docs and public catalogue only; no plant or job knowledge layers, no client or job names (tools/scrub.py clean). The intro deck is left out of this snapshot because its slide images could not be checked for job drawings.
214 lines
10 KiB
Markdown
214 lines
10 KiB
Markdown
# 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.
|