Dimension Lines vs Real Edges: 9 Cases an AI Got Wrong

 Part 3 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it.

Every drawing carries two kinds of line that look nearly identical to a machine and completely different to a person. One is the edge of real concrete. The other is a graphic whose only job is to say how big that concrete is.

This post is about the second kind being easier for a computer to find than the first. That inversion cost more of the 45 days than anything else.

1. Two layers on every sheet

Automatic line detection on the left utility detail. Red and blue mark detected segments — and they cover the dimension lines exactly as confidently as they cover the wall of the duct.

The same detector on the right detail. Every extension line, witness line and leader is a clean straight segment. Nothing in the raster says which of them is a real edge.

The traced outline with numbered vertices, isolated from the sheet. Getting to this from the image above is the entire problem of Part 3.

	Geometry line	Dimension / annotation line
Meaning	Outline of a real member. Where concrete is	A graphic that says how big it is
Substance	Yes	No
Counted in quantities	Yes	No
Extruded to 3D	Becomes a solid	Becomes a fake solid

A human separates them in a tenth of a second using six cues: line weight (geometry heavy, dimensions thin), end treatment (arrowheads or slash ticks), adjacent text (a number beside the line), standoff (extension lines start away from the member), line type (continuous, dashed, chain-dot), and layer (in native CAD they were never together).

Almost none survive an embedded Excel image — and the input here was a PNG inside a workbook, not CAD.

Human cue	Survives rasterisation?
Layer	Gone entirely — the concept does not exist in a bitmap
Line weight	Almost gone — anti-aliasing smears 1 px against 2 px
Line type	Partly — but detected as several short solid segments
Arrowheads and ticks	Yes — but detected as part of the line
Dimension text	Yes — but not linked to the line beside it
Standoff	Yes — but a human must choose the threshold

What is left is pixel brightness. The extractor that turned these drawings into vectors did exactly one thing: threshold everything darker than RGB 90, find runs along rows and columns, and merge them. To the machine a drawing is a set of trails of dark pixels. Hence the inversion:

Dimension lines are easier to detect than geometry lines.

Dimension lines are long, straight and axis-aligned; geometry is a chain of steps, slopes and short kinks. The extractor kept anything over 34 px as a geometry candidate and anything over 70 px as a "long line" — and on both utility crops, 39 of the roughly 73 detected segments qualified as long lines. In the first detection overlay — horizontal runs red, vertical blue — the 100/500 dimension stack, the l_barr_z4 and l_barr_y extension lines and the 125/300 lines under the drain pipe were thickly covered, while the stepped outline of the utility body stayed plain black. The machine saw the least important lines on the sheet best.

And pictures inside a spreadsheet are not to scale: a small rectangle in a detail view is a symbol meaning "there is an opening here", with the exact size in a cell. A machine takes a ruler to the picture. How far off the ruler is, measured later: the whole-section raster calibrates at roughly 0.045747 px/mm, which puts the 30 mm pavement layer at about 1.37 px — and the drawing renders that gap as 14 to 16 px. The picture exaggerates a thin layer by a factor of ten so a human can see it, which is correct drafting practice and catastrophic input. Worse, the same source image is not even uniformly scaled: its measured numeric-axis anisotropy is 5.806802%, and its own R1 horizontal radius disagrees with its vertical one by 19.685057 px. There is no single scale factor that makes that picture correct.

The date this was already known

On 26 June at 23:06, the first role-classified structural trace was written. It split each side of the utility detail into 15 production lines plus 1 reference line, and its description states the principle in one sentence:

Text and dimension extension lines are excluded from production geometry.

That is the correct rule, written down, on day nine, before any of the nine cases below happened. Every one of them happened afterwards. Three of them are the same confusion recurring — including once inside a filter written specifically to prevent it.

Knowing the rule is not the same as having a test for it. The rule says what to exclude; it does not say how to recognise what to exclude. The rest of this post is the seven weeks spent converting one true sentence into something a program can check.

2. The case catalogue

Case 1, left opening: the symbol as drawn does not agree with the dimension text written beside it.

The right-side opening symbol measured off the source raster at roughly 213 x 334 px. The written dimension next to it says something else — the symbol is schematic, not scaled.

Case 3: a box region containing two dimension lines and nothing else. There is no way to tell from the picture which member, if any, those dimensions belong to.

Nine things that actually happened, each as what happened / why the AI decided that / how it surfaced / how it was fixed / how to generalise.

Case 1 — a triangle became a part called "drain cradle"

What happened. A closed four-point polyline annotated closed drain cradle below the D300 pipe was registered as a real solid. Its coordinates formed a triangle: base 300 (drain pipe diameter), height 50 (clearance under it), area 7,500 mm². The code confessed outright:

drain_cradle_bed = closed_polyline([
    pocket_inner_bottom,     # a point on the pocket floor
    pocket_outer_bottom,     # a point on the pocket floor
    drain_pipe_bottom_point  # the lowest "point" of the pipe
])

Three feature points belonging to other members. Nothing about this triangle is its own; it has no vertex that exists because a designer put it there. Beside it, drain_cradle_axis was a plain vertical dimension line sharing the gutter's colour and coordinates — so the pair was a dimension graphic and its extension line, rendered as a structural component and a structural edge.

Look at the two numbers again: 300 and 50. Both are printed on the drawing as dimension text. The triangle's base is exactly the pipe diameter and its height is exactly the clearance under the pipe. A real cradle would have a bedding thickness, a haunch angle, a width that exceeds the pipe by some cover — some dimension of its own that is not simply another member's dimension repeated. It had none.

Why. Two failures compounded. First, it trusted the note over the coordinates: the payload said "cradle", and a cradle is a part, so it registered a part. Second, it applied an unstated rule — closed means material. Three points always close. Closure is a necessary condition for a solid, not a sufficient one, and it was being used as sufficient.

How it surfaced. Not code, not a gate. The user looked at the screen: "Isn't that yellow triangle a dimension?" By then it had rendered as real geometry in six detail views, and had propagated downstream into the Revit add-in's part catalogue and its sump void list — meaning the error had already crossed from "a wrong picture" into "a wrong instruction for cutting material out of a solid".

Fixed. Demoted Solid → ControlLine, its server usage moved to audit_trace_context, note corrected to CONSTRUCTION EVIDENCE (not a physical part), removed from the production group, from seven places in the viewer's part and material lists, and from the add-in catalogue and sump void list.

A trap sat inside the fix. The day before, only the add-in was corrected and the viewer was not — the same object, two codebases, one of them updated. The next day's message was "there's still something wrong left in the section", and only then was a sweep of all 15 detail views run. That sweep is where Case 2 came from. So the cost of Case 1 was not one misclassification; it was six views, an add-in catalogue, a void list, a partial fix, a second complaint, and a full sweep.

Read the coordinates, not the note. A closed shape of three or four points whose edges match printed numbers (300, 50) exactly is a picture of those numbers, not a part. And when you fix a shared object, fix every consumer in the same pass — a half-fix costs a whole extra round trip.

Case 2 — 13 of 15 polylines in the barrier branch were annotation

What happened. Each barrier branch held 15 polylines, sat in the production list, and rendered in the same colour as geometry. Only two were closed.

Index	What it is	Points
[0]	Barrier body	11 (closed)
[14]	Foundation	8 (closed)
The other 13	4 horizontal l_barr_z dimension lines, 5 vertical l_barr_y dimension lines, 4 hatch lines at 599.9 mm spacing	open

The old branch note read Excel barrier labels — it had written down that it was labels and was in the geometry list anyway.

Why. The name was BARRIER_*, so production status was judged at branch granularity; heterogeneous contents were never a check item. Hatching was the dangerous part — in coordinates, 599.9 mm spacing is four perfectly regular parallel lines, and regularity looks designed. A four-line hatch pattern has better internal consistency than any real member outline in the file. Every heuristic that rewards regularity ranks it above the thing it is decorating.

How it surfaced. Second finding in the 15-view sweep triggered by Case 1 — not because anyone pointed, but because "check all of them" was executed literally.

Fixed. split_closed_lines() introduced; the 13 open ones moved to BARRIER_ANNOTATION_LEFT/RIGHT (audit layer). BARRIER_LEFT: 15 → 2; payload branches 69 → 67. The source contract was rewritten at the same time, and its wording is the whole lesson:

The Excel crop contains two open material-edge chains. Y/Z dimensions and label leaders are review graphics, not material or reinforcement.

Branch ownership was then split four ways, with a fifth rule attached to the profile branch:

Branch	May contain
BARRIER_*	Closed material regions only
BARRIER_CONTROL_*	Source-aligned open shoulder and R23 transition edges, contact controls
BARRIER_DATUM_*	Y/Z datum lines only
BARRIER_DIM_*	Dimension and leader graphics only
SIDE_DETAIL_PROFILE_*	Real closed regions and holes — and no automatic last-to-first chord for an open source chain

The postscript is the most damning measurement in the project. Some months later, an independent contract check took the two locked material edges out of the original crop — the shoulder notch edge (source points P02 to P13, 12 points) and the R2/R3 transition edge (P13 to P18, 6 points) — and confirmed each was traced at 100.00% pixel coverage. It then asked a different question: how many of those real source points appear inside the branch that claims to be the barrier?

0.00%.

The branch reported closed: true. It was closed by a straight chord of 320.436088 mm drawn from P21 back to P00 — an invented segment joining two ends that the drawing never joins. The verdict recorded against it:

This is a closure test failure, not an acceptable solid.

Read that together with the previous paragraph and the failure mode is complete: a shape can be perfectly closed, pass every topology check, and contain none of the real edges of the thing it is named after. "Closed" measures the polyline. It says nothing about where the polyline came from. And the automatic last-to-first chord — the convenience that makes an open chain into a closed region — is the exact mechanism by which an honest open trace becomes a dishonest solid. Hence the fifth rule above, which forbids it by name.

One more number from that check, worth holding on to: the barrier reference image exists 34 times in the workbook with 1 unique hash. Thirty-four byte-identical copies. Whatever that crop shows, it does not vary by section.

Do not trust the branch name; count it polyline by polyline. Open lines inside a member branch are almost certainly annotation, and hatching is not geometry. Then ask the harder question: does this closed region actually contain the source edges of the member it claims to be?

Case 3 — falling into the same trap a third time

What happened. After filtering I reported "only the two closed ones remain, done." The user put two orange check marks on the screen and pointed again. The second survivor was not the foundation but opening_guard_profile — a construction aid at a fixed 50 mm offset from the opening to the road-side face of the utility body.

Two properties settle it. It has no Excel dimension of its own: it is generated entirely from opening boundary + 50 + utility detail height, three inputs that all belong to other members. And it overlaps the real barrier outline, so promoting it to a solid would place material twice in the same space — a defect that a boolean union hides completely and a quantity take-off reports as extra concrete.

Why. Case 1's reason again — closed, therefore material. Read that carefully, because this is the part that matters. The filter written to fix Case 1 tested closure. Case 1's actual cause was treating closure as sufficient. So the remedy was built on the same assumption as the disease. It correctly removed 13 open annotation lines and was structurally incapable of noticing a closed one.

How it surfaced. The user pointed again. The gates were green.

Fixed. Split out under BARRIER_GUARD_* into the annotation layer (13 → 14); viewer caption 38 polylines / 26 closed → 36 / 24.

A side trap wasted an afternoon: after the fix, the API kept serving the old values because the payload disk cache would not refresh even with ?reload=1. Forced rewrite plus a server restart was needed. For a while the evidence said the fix had not worked, which is indistinguishable from the fix not working.

Final verification: zero triangles or hatch lines anywhere in any detail view, with 12 open lines deliberately retained — slab end faces, road surfaces, edge controls — as named boundary lines that genuinely exist on the drawing. Note that the answer was not "delete every open line." Twelve of them are real. The rule had to be about origin, not about topology, precisely because topology cannot distinguish these twelve from the thirteen that were removed.

A trap catches you again even after you build a filter, because the filter caught a symptom. The real test is not "is it closed" but "what inputs built this shape?" — a shape generated with no dimension of its own, purely from other members' coordinates, is a construction aid. That one line catches Cases 1 and 3 together, and it is the only formulation that does.

Case 4 — drawn size disagrees with written size on 132 of 132 sides

What happened. Across all 66 frames, the utility opening's drawn size and its cell value never agreed.

	Cell value	Measured off the drawing	Difference
Left opening	300 × 300	217.74 × 333.87	W −82.26 / H +33.87
Right opening	200 × 300	212.90 × 333.87	W +12.90 / H +33.87

Sides inspected 132 (66 frames × left/right); conflicting sides 132, every one; max errors 82.26 mm wide and 33.87 mm high.

The error size is not the point. Read the table vertically instead of horizontally. The cell values differ — 300 versus 200, a 50% difference in width — while the drawn widths are nearly identical, 217.7 and 212.9, within 5 mm of each other. And the heights are 333.87 on both, exactly equal to the last two decimal places.

Two openings that the design says are different sizes are drawn the same size, to a precision of hundredths of a millimetre. That is not a drawing error. That is the same picture stamped twice. The conclusion follows without any argument about which value is right: whatever those rectangles are, they are not measurements of these openings.

Why. It treated "measured off the drawing" as a measurement. A human seeing a small figure in a detail view flips a switch that says "schematic"; the machine has no such switch, and — worse — its measurement is excellent. It is repeatable to two decimal places across 66 frames. High precision on a meaningless quantity is the most convincing kind of wrong number.

The same pattern shows up per role when the production geometry is scored against the raw image, and the numbers separate cleanly:

Role	Raw similarity	Centre	Size
Utility body	100.0 %	100.0 %	100.0 %
Utility opening	76.1 %	85.7 %	66.5 %
Sump pocket outline	91.9 %	93.9 %	89.0 %
D300 perforated pipe	54.0 %	91.4 %	8.5 %

The utility body — the largest member, the one drawn at something close to real scale — matches the picture exactly, 100% on all three measures. It is the only role in the file that does. Everything small degrades, and the smallest thing degrades most: the D300 pipe is in almost exactly the right place (91.4%) and almost entirely the wrong size (8.5%).

A separate bounding-box comparison run on the same day gives the same story in pixels, across eight rows:

Role	Max bbox delta	Centre delta (X / Y)
Utility body	0.0 px	—
Utility opening	49.273 px	—
Drain pocket outline	30.364 px	left −9.125 / 12.898 · right 9.25 / −14.079
Drain pipe	132.0 px	left 0.0 / 15.398 · right 0.0 / 0.921

The drain pipe's bounding box is off by 132 px and its centre is off by 0.0 px horizontally on both sides. Right column, wrong diameter. If you were still tempted to treat the picture as a measurement, that row settles it: the picture is authoritative about position and worthless about size, and those two facts are true of the same object at the same time.

How it surfaced. Not automatically. The validator passed, because it checked against the cells; the disagreement had to be made into a comparison before it existed at all. Somebody had to write a tool whose only purpose was to ask a question nothing was asking.

Fixed. Authority split per property — centre from the Excel trace, diameter from the numeric label — and the split drawn into the overlay PNG itself, with a legend:

Dashed grey = raw Excel symbol scale / audit reference. Solid colour = numeric-dimension production geometry.

That legend is the cheapest fix in this entire post. Two line styles, one sentence, and every subsequent viewer of that image can see which authority produced which line without being told.

The conflict was then preserved as audit evidence rather than hidden. One report carries, simultaneously: production dimension error = 0.0 mm and raw bbox delta = 132.0 px. Elsewhere the maximum production-to-image-trace deltas are recorded as 109.274 mm for the utility opening and 89.218 mm for the D300, with the note: these deltas are not hidden and are not converted into a visual pass. The production profiles themselves became closed 13-point numeric outlines at 300 × 300 and 200 × 300 — the cell values, not the drawn ones.

And the opening did get its ruling. It sat in the authority table as Excel cell — awaiting adjudication until the night of 14 July, when the answer came back in one sentence: the cell is production truth and the drawing supplies the topology only — and since this is a variable region, the user edits the cell. What that did not settle is the residue it exposed. The body's recess is still 217.7 wide against a cell that says 300, and closing an 82 mm gap needs an anchor rule — which corner holds while the other moves — that was recorded as a follow-up and never supplied. The authority question is answered; the reconciliation is not. (The full account of that night is in Part 8.)

If a member has a mirrored twin, use the twin as a cross-validator. Different labels, same picture → the picture is a symbol; same label, different pictures → the picture is a measurement. And check position and size separately: a symbol can be in exactly the right place.

Case 5 — the opposite failure: 528 dimension lines collapsed to points

The first four cases are "a dimension was mistaken for geometry". This one is the mirror image: a dimension was drawn correctly and revealed that the geometry was missing.

What happened. An Excel-reflection audit turned up 528 mismatches — 4 keys × 66 frames × left/right.

Dimension key	Label value	Measured from geometry
Utility left/right ledge	50	0
Notch drop	60	0
Top step	150	300

Ledge and notch drop measured zero: both endpoints converged on one coordinate, so the line collapsed to a point.

Why. The anchors were tied to real feature points — correct by design; that is what makes a dimension line follow the geometry when the geometry changes. The fault was that the geometry builder was not producing the step: the opening profile generator constructs the ledge with zero width, so the dimension honestly drew "there is nothing here". The dimension was not lying. It was reporting.

Then it got worse. 50, 60 and 150 were not Excel cells. They were code constants, tagged HARDCODED_DEFAULT, living in the server. So the instruction — make the utility dimensions match Excel — was literally impossible to execute: there was no Excel value to match. Two more values in the same family, the PVC pipe sizes, had the same status. Six labels, all presented in the payload as if they had come from the workbook, none of which had.

Note the compounding here. Part 2 was about numbers hardcoded in a Dynamo graph. This is the same disease reappearing one layer downstream in the web server, three months later, in a system built specifically to eliminate it — and it was invisible for exactly the same reason: a number with no provenance tag looks identical to a number with a good one.

How it surfaced. Only in an exhaustive accounting of every Excel dimension: 121 keys, mutually exclusive classification, zero unclassified. The word "exhaustive" is doing the work. On screen these dimension lines were invisible — a zero-length line renders as nothing — and nobody complains about what they cannot see. The 528 failures existed for as long as the feature did and were found the first time somebody demanded that every key be accounted for in exactly one bucket.

They also had a consequence at the top of the evidence chain. The source authority manifest, generated weeks later, carries status FAIL with a single issue: DIMENSION_TRACE_NOT_PASS, sourceIssueCount = 0, issueCount = 528. Zero problems with the source. 528 problems with the dimensions bound to it. The manifest was honest about failing rather than reporting the source's clean bill of health.

Fixed — still unfinished. Cause confirmed. The rule applied was:

If following the value breaks the geometry, report it as a candidate defect in the source workbook and request manual adjudication. No silent correction.

The four hardcoded labels plus two PVC values were recorded as evidenced by markings inside the image — a provenance class of their own — and explicitly not promoted to cell status, because there is no cell. The reflection ledger that tracks this ran with a backlog of 8 unresolved keys, later reduced to 5 as three were promoted to confirmed drivers.

Drawing the dimension lines exposes the geometry's lies — collapse to a point means the geometry has no such step. It is a free validator. And tag every number's provenance before you are asked to reconcile it, or "match the source" becomes an instruction nobody can carry out.

Case 6 — ghost keys that came from code defaults

What happened. The payload exposed sump spacing = 50 m and drain PVC spacing = 10 m, which look exactly like design parameters — right magnitude, right units, plausible engineering values, sitting in a data structure derived from the workbook. An exhaustive search found them in no cell and in no image. They were injected two lines apart in the server source and flowed out through the payload as data.

Why. The unstated assumption "it is in the payload, therefore it came from Excel". The payload is a derivative of the workbook, so its contents were treated as workbook-derived by default. Nothing in the structure distinguished a value that had been read from a value that had been supplied.

How it surfaced. In the exhaustive audit of Excel images against dimension-reflection status. And there is a detail that makes this case unusually clean: both values could never appear on a cross-section at all. They are longitudinal spacings — how far apart sumps are along the tunnel — and a cross-section is a cut perpendicular to that direction. A human with the drawing in front of them would never have looked for them there. The audit found them precisely because it was not reasoning about what a cross-section can contain; it was reconciling two lists.

Fixed. Confirmed as not-reflected, and recorded: marked UNREFLECTED_GHOST_CTC in the code at the point of injection, with a "final: not reflected" section in the audit report. No geometry work. The values were left in place, labelled, rather than deleted.

That choice is deliberate and worth defending. Deleting them would produce a clean payload and an unrecorded decision, and the next person to notice that sumps have no spacing would supply one. The marker is a note to the future saying this was examined, it has no source, do not invent one.

"Not reflected" is also a conclusion. Delete an unsupported value silently and the next person invents it again. Tag provenance — Excel cell / drawing marking / derived rule / code default — because the fourth, unmarked, is a ghost.

Case 7 — asking "which member is this?" about a box holding only dimensions

What happened. Bottom-left of the sheet sits a block with 100 and 500 stacked vertically. The AI drew a green box round it and asked — "the drawing's channel 100×500 marking, which member's section is it?" Inside that box there is not a single member outline: two dimension lines, tick marks, and the numbers.

Why. Two failures, both linguistic rather than geometric. Two dimension lines meeting at a right angle look like a rectangle — a corner is a corner whether it is made of concrete or of extension lines. And "100×500" is grammatically identical to a member size designation; in steel and concrete detailing that string almost always names a section. So the question was constructed on the premise that a member existed and the search for it was failing. The AI asked a well-formed question about a thing that is not there.

How it surfaced. It did not. It was logged as "not reflected — corresponding member unknown" and put into the 14 July question set, where it came back the same night — but with a construction rule in place of a name: from the 150 level, offset uniformly by 100, drop 500, and treat the remaining space as a separate closed polycurve. That was enough to build with, and it pointed at two workbook cells the AI had been walking past for a month. The sub-question that asked which member it is was never answered, and it is still not.

Fixed. Eventually, and not by guessing: nothing was drawn until the rule arrived. The strip that exists in the geometry now was built from the answer and from those two cells, and it carries a branch name the AI invented rather than one the engineer gave. No member was invented from a guess — but no member was named either. (Part 8 works through the exchange.)

Put the ledger side by side. Case 7's total cost, to date, is one identification that never came back. Case 1's total cost was six detail views, seven viewer lists, an add-in part catalogue, a void list, a partial fix, a second complaint from the user, and two full sweeps. Both began with the same thing: an ambiguous cluster of lines that might or might not be a member. The only difference is what was done with the uncertainty.

Asking a wrong question costs nothing. Guessing made the same uncertainty a hundred times more expensive. The expensive failure mode is not being wrong; it is being wrong and downstream.

Case 8 — what does the markup point at? The R2 endpoint, fixed three times

What happened. The user screenshots the viewer, draws red dots, and sends it back with "it has to end here" — but that screenshot contains lines from the original drawing and lines the AI drew, together, with nothing to tell them apart.

Round	Instruction	AI's reading	Result
v6	"r2 and r3 have to connect at the ARC ends like this" + markup image	Moved both R2 and R3 to the drawn toe point	Lining band self-intersected → discarded
v7	"the current endpoint is probably right for r3's termination. change r2's, refer to the image"	Terminated R2 at the upper boundary intersection	Close, wrong location
v8	"I said the R2 endpoint has to come beside the top of the [utility body]"	R2 = utility body top outline ∩ topmost point of the R2 circle	Settled

Why. The markup's target was ambiguous, and the same rule was applied to R2 and R3 at once when their termination rules differ. This is the most abstract form of the confusion: of two points on one screen, one is a fixed feature point the drawing decided, the other a derived point set by its relation to another member — identical red dots in pixels.

The user later put it exactly: "the reason there's no dimension on that R2 endpoint is that its position adjusts depending on the situation." Absence of a dimension was itself the information; a machine reads it as "no information". In drafting convention, a dimensioned point is fixed and an undimensioned point is derived — the absence is a positive statement, and it is the single hardest thing in this entire post for a program to recover, because it is encoded as nothing.

How much it varies was measured afterwards: the R2 endpoint's z ranges from 396 to 612 across stations. It genuinely has no fixed value. Any attempt to give it one is wrong at 65 of 66 frames.

How it surfaced. A dedicated correction document, opening:

The user's red dots are not annotation dots, and not slab/drain trim points. They are the final terminal endpoints of the R side arcs.

The code was in fact using the slab/drain trim point there. The coordinates make the size of the confusion concrete. On the first section's start frame, in millimetres:

Point	Left	Right
R2 arc terminal endpoint	[−8953.836, −11.385]	[63.696, −281.274]
R3 arc terminal endpoint	[−8958.495, −161.245]	[59.390, −431.188]
Slab production trim point	[−9545.707, −16.294]	[1166.364, −299.894]
Lower production trim point	[−9480.995, −221.196]	[1120.609, −504.796]

The R2 endpoint and the slab trim point are about 592 mm apart on the left side and roughly 1,100 mm apart on the right. On screen, at viewer zoom, both were the same red dot. A second measurement from a different frame puts the distance between the correct R3 endpoint and the wrong upper trim point at 214.878 mm on the left and 209.948 mm on the right — and at that scale the two dots overlap.

Everything else about the geometry passed. Seven validators, all pass: true, issueCount: 0, R2 topology across 66 frames and 132 sides, R3 start/end/radius checks all 132. The gap between R2's end and its source endpoint measured 0. The gap between R2's end and R3's start measured 0. The chain was perfectly continuous — and terminating in the wrong place.

Fixed. A dedicated R23_ARC_ENDPOINT_LOCK_* branch separating endpoint authority by role name; slab trim, lower trim and drain connection points marked as distinct downstream connection points; and a rule nailed into acceptance:

No code path may substitute a slab/drain trim point for an R-arc termination.

Plus a markup convention: one word saying drawing-or-AI, fixed colour meanings, and the member name written on the arrow.

Even that was not the end. The R2/R3 endpoint question generated correction documents on four separate dates across nine days, and each one records a different way of getting it wrong:

• Treating the red dots as annotation points or slab-drain trim points.
• Labels reading purple = lower no-dim source lock that misled the visual review — the label itself became a source of error.
• An instruction to shorten two connector runs being implemented as replace them with a direct diagonal. That was reverted, with the note: the requested change was to shorten the two connector runs; it was not a request to replace them with a direct diagonal line from the R2 endpoint to the R3 endpoint.
• R2 and R3 terminating on a detached remote vertical closure — a line separated from the utility, drain and slab detail entirely, and not the physical trim face at all. Rejected by the user.

The rules accumulated in response read like a list of shortcuts that had each been taken once: a direct R2-to-R3 diagonal cap is forbidden; long upper/lower level lines extending from the arc endpoints to remote side-detail geometry are forbidden; the source-to-contact ties are axis-aligned polylines and a direct diagonal end chord is forbidden; no detached vertical line, long level run or remote connector is allowed. Five legacy branch families were named and permanently barred from the production payload.

The eventual resolution was to stop describing the endpoint by position at all. Both user markers were found to resolve to a single value — a 60-degree R2 terminal sweep — so production uses exactly 60 degrees rather than a sampled point index. And the shape between the two arcs was fixed as an explicit path: R2 endpoint → 100 mm upper run → shaped side-lining return → 100 mm lower run → R3 endpoint, with the 100 mm coming from the Excel side-detail lining offset. Measured on the first frame: eight path points, upper run 100.0 mm, lower run 100.0 mm, endpoint gap 0.0 mm, with intermediate segments of 100.0, 96.4, 150.0, 147.7, 139.8, 4.5 and 100.0 mm on the left.

Forcing three exact authorities at once — exact Excel radius, exact R1 start, exact Excel-detail endpoint — has a price, and the audit reports it rather than hiding it: the R2 centre ends up 324.055 to 746.989 mm from its former guide centre, R3 866.785 to 1307.915 mm, with tangent breaks of 4.695–10.876° and 10.840–16.486°. The note attached says these values expose the incompatibility between the three requirements. Nobody made them go away. They were published.

Draw two things on the same screen and they become the same thing. Separate them by role name (branch), not colour. "No dimension written here" is a signal, not a gap. And when a point cannot be pinned by position, pin it by rule — 60 degrees is checkable; "beside the top of the utility body" is not.

Case 9 — reading "must meet the slab" as "move the part"

What happened. The instruction: "the green part below. it has to meet the slab and resolve the geometry cleanly." The AI snapped the sump pocket vertices to Excel cell coordinates, and the raster comparison collapsed — right-side p95 from 8 px to 18 px. Reverted.

Why. It applied one principle to every region: "Excel is production truth". By that principle, if two things must meet, moving one to its cell coordinates is the correct move. The principle is right most of the time. It is wrong here, and nothing in the instruction says so.

In fact three separate things were wrong with the reading. Authority for the pocket ring is the original drawing trace, and cell snapping is forbidden for it. "Must meet" meant a connection must exist, not that either member should move. And the drawing already had the connecting segment on it — the answer was sitting in the source image, already drawn, waiting to be traced.

How it surfaced. The raster metric collapsed numerically. This is the rare case where an automated number moved first, and it is worth being precise about what the number did: it said worse. It did not say why, and it did not say what the correct action was. "Why" came from re-reading the instruction and noticing that "meet" has three possible implementations.

Fixed. Reverted; a separate connecting member added; and the authority table gained a permanent row: "pocket ring shape = original drawing trace, cell snapping forbidden — demonstrated by raster collapse." The phrase demonstrated by raster collapse is doing real work there. It records not just the rule but the evidence for the rule, so that the next person who thinks Excel should win everywhere has the counter-example attached.

"A must meet B" does not necessarily mean "move A". Move A, move B, or build a connecting member — and if the drawing has a connecting segment, it is the third.

3. The same error at pixel level

The discrepancy contact sheet. The yellow triangles mark places where a dimension line was reconstructed as if it were a member — this is what the failure mode looks like once it is downstream.

The nine cases above are about classification: is this thing a member or a graphic? There is a lower-level version of the same mistake, and it produced the single most precise piece of evidence in the project.

A branch named SIDE_DETAIL_SOURCE_GEOMETRY_* was supposed to hold nothing but traced source lines. A correction document lists five root causes for why it did not, and the first is the purest instance of this post's subject:

The right drain pocket followed dimension/leader geometry after its first two points: (162,368) → (228,469) → (416,469) → (494,384).

The tracer started on the real pocket outline, and two points in, the strongest continuing dark trail was a dimension line. It followed it. Look at the middle pair of coordinates: (228,469) → (416,469) — 188 pixels at exactly constant y. Real pocket outlines in this drawing do not run 188 px dead level; dimension lines do. The trace is a picture of the moment a geometry follower changes lane onto an annotation.

The other four root causes are worth listing because none of them is a geometry bug:

1. The right pipe symbol was centred at (316,433) instead of the actual Excel symbol near (258,427) — 58 px off in x.
2. Both lining curves were sparse approximations displaced by tens of pixels from the visible curves.
3. The branch named SOURCE_GEOMETRY was reading a normalised production trace, so the drain pocket could already have been replaced by generated geometry. The branch name said source geometry; the contents were not.
4. The viewer's title still called the lower panel production, which obscured the contract error from anyone looking at it.

Causes 4 and 5 are labelling failures, and they are the reason the pixel errors survived. A panel titled "production" showing source geometry, and a branch called "source geometry" holding production geometry, cancel each other out on screen: everything looks consistent and everything is mislabelled.

The fix was to declare the acceptance criterion before measuring — a fixed 3-pixel search radius and a 98% minimum coverage threshold announced in advance — and to write down explicitly what does not count as geometry:

Excluded from this comparison: dimensions, text, labels, leaders, shoulder datums, relation helpers, generated utility boxes, the generated D300 pocket replacement, and every production-normalised substitute.

Five ordered source roles per side were then locked — outer lining outer curve, outer lining inner curve, source cutline solid outline, drain pocket outline, drain pipe — at 10, 10, 22, 4 and 41 points respectively. The resulting coverage:

Role	Left	Right
Clean cutline	100.000%
Lining outer / inner	100.000% / 100.000%	100.000% / 100.000%
Pocket / pipe	99.628% / 100.000%	99.631% / 100.000%

Zero issues across 33 sections, 66 frames, 132 checked geometry sides. Note the discipline in the order of operations: the threshold was fixed at 98% before the numbers came in at 99.6%. Had it been chosen afterwards it would have proved nothing.

The same document retracts an earlier claim, and the retraction is the most valuable sentence in the file:

14/14 closed was a topology result, not visual fidelity evidence. The earlier comparison mixed generated closed regions, dimension-derived boxes and helper diagonals into a view presented as if it were an Excel-shape comparison.

An identical correction was pasted into the header of the report that had made the original claim: the former 14/14 closed result proves only that the generated production regions are closed. It does not prove that the lower comparison drawing matches the Excel image. Two documents, both amended in place rather than quietly replaced.

4. Why this class of error is uniquely dangerous

Authority made explicit on the image: dashed grey is the raw drawn symbol, solid colour is the production geometry driven by the numeric dimension. Per part and per property, one of the two wins.

The drain dimension-authority diagnostic, left and right. The red note on the sheet is the important part: because the trace reuses source anchors, this view cannot approve independent visual fidelity.

It produces plausible output. A dimension symbol that happens to be a closed polygon renders without complaint. Nothing breaks, so no "something is off" signal is generated at all — and hatching looks more convincing for being too regular.

The numeric checks pass. Reports from a single moment, side by side:

Metric	Value
Dimension check	PASS
Visual comparison	FAIL
Discrepancy count	6
Opening dimension error	0.0 mm
Conflicting sides vs. original drawing	132 / 132 — every one

That gate reports technicalDimensionPass = true and visualMatchPass = false in the same object. Its six mismatch rows, by role: left utility opening 76.1%, left drain pocket outline 92.9%, left D300 pipe 64.0%, right utility opening 90.0%, right drain pocket outline 91.9%, right D300 pipe 54.0%. And its named visual defects are things any engineer would spot in a second: shoulder notch missing or reshaped; stepped sidewall mismatch; drain pocket integration mismatch; slab start connection mismatch.

The drain authority contact sheet is a better example still:

LEFT  pocket p95 1.5 px,   D300 p95 0.458 px
RIGHT pocket p95 1.347 px, D300 p95 0.458 px

A p95 of 1.5 px reads as essentially perfect. The same sheet says, in red:

This proves dimension-authority reconstruction only. The independent Excel raster state is unchanged.
(Diagnostic only: source trace anchors were reused, so independent visual conformance cannot be approved.)

Geometry built from dimensions was scored against dimensions — the same premise as input and as marking scheme. Not verification: a tautology. And the tautology is not obvious from the number. 1.5 px is exactly the kind of figure that ends a review.

The discipline that survived was to make reused-lineage evidence a blocking state rather than a passing one. The rules written into the independent-scope inventory:

• A technical dimension or topology PASS cannot approve an Excel visual match.
• A scope needs original PNG source pixels, separately rendered production branches, distinct fingerprints, a current payload version, and bidirectional holdouts.
• Missing, stale, one-way or same-lineage evidence is a blocking state, never zero error.
• User visual approval remains a separate checkpoint after every independent scope passes.

That third rule is the important one and it is counter-intuitive: absent evidence must score as failure, not as zero. The natural implementation — no image, no comparison, no error, therefore pass — turns a missing input into a green light. Under these rules, four of six scopes were sitting at STALE_EVIDENCE and the overall verdict was INDEPENDENT_SCOPE_MISMATCH, with approval eligibility false on all six, at a moment when every dimension gate in the system was green.

The same insistence shows up as a repeated prohibition across many documents, phrased slightly differently each time and always meaning the same thing: rerun the locked comparison, do not change thresholds to obtain a pass; these failures must remain visible and cannot be converted to PASS by reusing the same source trace or enlarging tolerance after the result; any change that breaks a locked validator must be rejected rather than hidden by weakening that validator; do not fit the sign to the raster result. Four separate authors of four separate documents all felt the need to write down that you must not move the goalposts, which tells you how strong the pull was.

Only eyes catch it. Discovery path across all nine:

Discovery path	Cases
User spotted it on screen	4 (1, 3, 8, 9)
Full sweep triggered by such a catch	1 (2)
Exhaustive accounting / audit report	3 (4, 5, 6)
Automated gate, on its own	0

Zero. And note that the three found by "exhaustive accounting" were found by audits written specifically to look for this class of problem — a comparison tool built to ask whether the picture and the number agree, a ledger built to classify 121 keys with none left over. Those are not routine gates. They are gates that somebody designed after already suspecting the answer.

So the contract states that validator pass proves branch existence, closure and conformance to the contract rules — nothing more, and the comparison sheet header says it outright: "Closed polygons and numeric-dimension PASS do not equal visual completion." That became a project-wide rule: the instruction's own conditions go into the gate first; a PASS from a gate that ignores them is void.

And it gets more expensive downstream.

Caught at	Scope of the fix
Drawing interpretation	One line of classification
Viewer	One branch
Payload	Viewer + payload + the paired validator
Revit solid	All of the above + add-in part catalogue + void list + redeployment and hash verification

Case 1 went all the way to the last row. And the last row is worse than it looks, because a wrong solid is not merely a wrong picture — the add-in's void list drives subtraction, so a fake part becomes a real hole. Hash verification appears in that row because a related class of failure was traced to a stale binary: the fix was correct, the deployed file was not, and the symptom was indistinguishable from the fix not working.

5. Authority is per-part and per-property

The fix, step one: the barrier crop with only the dimension layer kept.

Step two: the same crop with only the geometry layer kept. Separating these two is what made the rest of the pipeline possible.

After classification: each surviving line is coloured by the role it was assigned. Compare with the first image in this section — same drawing, different question answered.

Geometry-versus-dimension is the surface; underneath is authority. The founding principle — Excel cells and labels are production truth, the drawing trace is reference only — is right most of the time. Apply it to Case 9 and the metrics collapse; apply it to Case 8 and there is no answer at all, because the R2 endpoint has no cell. Per-region exceptions exist, and the AI cannot infer which they are.

What eventually got written down was not one principle but a ranked list of six authority kinds, highest first — this is the manifest's own ladder, in the order the code applies it. It is a different list from the six drawing-level kinds later in this section, which are my grouping of a nine-row table rather than anything the source states as a taxonomy:

Rank	Authority	What it means
1	user_approved_interpretation	A human has ruled on this. Nothing overrides it
2	numeric_excel	An Excel cell, or an explicitly recorded Excel label scan
3	excel_image_topology	The embedded picture — for topology and placement, never for size
4	derived_formula	Computed from others; must list its dependencies
5	generated_output	Something the system produced
6	legacy_audit	Historical, retained for comparison only

The ordering earns its keep in two places. Rank 1 above rank 2 means a human ruling beats a spreadsheet cell — which sounds wrong until you remember Case 4, where the cell and the picture disagree on all 132 sides and somebody has to decide. Rank 3 restricted to topology-and-placement is Case 4's finding promoted into policy: the picture is authoritative about where and not about how big.

Five production rules were attached:

• Numeric dimensions come from Excel cells or explicitly recorded Excel label scans.
• Embedded images define topology and placement evidence; they are never pasted as production geometry.
• Derived formulas must list their numeric and image dependencies.
• Legacy, review-only, proxy or fallback authority cannot enter a production solid group.
• R2/R3 endpoint semantics remain awaiting user visual approval until the checkpoint.

And the regions were mapped to authorities in groups:

Anchor group	Authority	Roles
Road / tunnel centre datum	numeric_excel	road centre, tunnel centre, R centre
R1/R2/R3 numeric radii	numeric_excel	R1 inner, R2 inner, R3 outer, lining offset
R2/R3 endpoint semantics	user_approved_interpretation	R2 source end, R3 trim attach
Road and slab edges	numeric_excel	road surface, slab surface, slab end face, lower edge control
Utility and drain topology	excel_image_topology	utility body, opening, drain, ditch, cover, detail trim face
Barrier and support topology	excel_image_topology	barrier, reinforcement, grouting, forepoling

One row in that table is the entire Case 8 story compressed to a cell: the R2/R3 endpoints are the only group whose authority is a human ruling. Everything else resolves to a cell or a picture. Those endpoints resolve to neither, and three failed rounds were the cost of discovering it.

The six drawing-level authority kinds, one at a time

One caveat before the list. The source does not contain a taxonomy; it records authority region by region, in a table of nine rows. The six kinds below are my grouping of that table's authority column.

① Excel cell. A number in a cell drives the geometry directly. This is the default and it covers most of the model: the arch radii and angle, the road and slab layer thicknesses, the opening W×H, the pocket-to-slab connection. Its failure mode is cross-mapping — R2 and R2' are different values in adjacent columns, and swapping them produces a section that is entirely plausible and wrong on both sides. The authority table's note for the arch row is simply watch left/right cross-mapping.

② Drawing feature point. A point that exists because it is drawn there, with no formula behind it. The R3 endpoint is one. These are the easiest to honour and the hardest to find, because nothing distinguishes a deliberate feature point from an incidental vertex of a traced polyline. The only workable handling was to name them individually — P18, P19, P20, P21 became formally declared control points — so that later code could refer to them by identity rather than by index into a trace.

③ Rule (derived by relation). A point computed from a relationship with another member: R2 endpoint = utility body top outline ∩ topmost point of the R2 circle. This is the class that has no dimension by design, and therefore the class that a dimension-driven pipeline cannot represent at all. The important consequence is that a rule authority is verifiable in a way a coordinate is not: once the endpoint became "exactly 60 degrees of R2 sweep", it became a thing a validator could check on all 132 sides. A coordinate would have needed a tolerance and would have been wrong at every station.

④ Derived formula (additive). Another value plus a constant. Two live examples, both verified: the slab attachment level is road surface + 160, and measurement across frames put it at 160.1 to 160.4. The floor thickness is slab-end road z − body floor z = 487, exact on both sides. The rule attached to this class is that a derived formula must list its dependencies — otherwise it is indistinguishable from a hardcoded constant, which is exactly how Case 5's ghosts got in.

⑤ Original drawing trace. The shape is whatever was drawn, and no numeric source outranks it. The sump pocket ring is the canonical member here, and it earned this status the hard way in Case 9 — the entry in the authority table reads cell snapping forbidden, demonstrated by raster collapse. This is the authority most people forget exists, because it contradicts the founding principle. Sometimes the picture is right and the cell is not applicable.

⑥ Drawing literal. A number printed on the drawing with no cell behind it: the weep hole, the 50 mm cradle clearance, the 50 and 125 mm clearances, the 100 mm lining-side offset. These are real dimensions with real authority and no home in the workbook. Case 5 is what happens when they are not recognised as a distinct class — they get implemented as code defaults, and then an instruction to reconcile them with Excel becomes impossible. The resolution was to give them their own provenance tag — evidenced by markings inside the image — rather than promote them to cells they do not have.

The region table

Region	Primary authority	Basis
Arch radii and angles	Excel cell	Settled. Watch left/right cross-mapping
R2 endpoint	Rule — utility top outline ∩ topmost point of R2 circle; 60° terminal sweep	Settled. No dimension = z varies 396–612 by station
R3 endpoint	Drawing feature point	Settled
Slab attachment level	Derived formula — road surface + 160	Verified at 160.1–160.4
Opening W×H	Excel cell	Awaiting adjudication
Pocket ring shape	Original drawing trace	Cell snapping forbidden — raster collapse
Pocket ↔ slab connection	Excel cell	Settled
Weep hole, 50 cradle, 50/125 clearances	Drawing literal	Fixed dimensions as drawn
Floor thickness	Derived formula — slab-end road z − body floor z = 487	Exact both sides, verified

Under it sits the most honest sentence in the project: the general principle is "Excel = production truth, trace = reference", but there are per-region exceptions, and I cannot infer which they are.

Finer still: authority per property

Within the D300 pipe, centre position takes authority from the Excel trace (centre similarity 91.4%, and a measured centre delta of 0.0 px in x on both sides) and diameter from the numeric label (size similarity 8.5% — the symbol ignores scale). Position from the picture, size from the number, inside one member. No part-level authority assignment can express that, and getting it wrong in either direction produces a pipe that is either the right size in the wrong place or the wrong size in the right place.

The road slope is the same shape of problem in a different guise. The two superelevation cells are already signed (−0.03 and −0.02), the sheet contains a note explaining which side each applies to, and the code negated them anyway — twice, at which point the guardrail was written as do not negate the Excel slope cells again, followed by do not fit the sign to the raster result. After the correction the first frame's road surface reads [−9705, −291.15] → [0, 0] → [1005, −20.1] mm, and the independent raster deltas improved across the board — road surface from 18/19 px to 10/7, pavement bottom 32/32 to 13/13, slab bottom 29/29.4 to 11/10 — while the report still notes that all of them remain above the locked gate because of the schematic thickness exaggeration described earlier. A material improvement that is honestly still a failure.

Line type is authority too

Excavation is the arch offset plus the slab underside as a closed dashed line; shotcrete is a constant offset of that as a long-dashed line; lining generates tags only and changes no geometry. Same arch, three line types, three different things — and a raster smears that distinction into "several short solid segments", unrecoverable until a human says it in words.

The corresponding requirement, written into a later goal, is a four-way classification the viewer must be able to express: final production solids / production construction and dimension lines / raw Excel image and vector trace evidence / audit and helper geometry. Alongside it sits a rule aimed squarely at the failure mode of a system that draws its own annotations: a validator should warn if a displayed dimension label exists only as a drawing annotation in the front-end and cannot be traced back to payload or report evidence. In other words, the viewer must not be allowed to invent a dimension — which is the same disease as Case 6's ghost keys, one layer further out.

6. The fix — and what it actually reduced

A checklist item failing. The verdict printed under the comparison names what is wrong — shoulder notch, stepped sidewall, drain pocket, slab start — instead of reporting a score.

The cheapest thing we did was the most effective: cutting the barrier crop in two. A dimensions-only crop (thin lines, ticks, the 50 / 100 / l_barr_y labels and leaders — no geometry at all) and a geometry-only crop (the stepped barrier outline). Side by side, why the machine was confused is obvious instantly. Thirty minutes of image editing against seven weeks of inference.

Item	Before	After
Barrier branch polylines	15	2
Payload branches	69	67
Viewer detail-view caption	38 / 26 closed	36 / 24 closed
Triangles and hatch surviving in detail views	6 views	0

A second, larger reduction came from the same idea applied to the section inset. The drawing-style inset had been assembling five branch families and 21 closed polylines per side: 14 side-detail profile regions, 5 overlapping lining-band regions, 2 duplicate drain regions, plus slab-end and trim edges drawn on top of the same boundaries. Every one of those was legitimate geometry; together they were unreadable, and the overlaps were exactly the places where the user could not tell a member edge from a helper.

The final inset consumes five visible production section lines per side. The recorded result: three branch families, five visible polylines, two closed outlines, verified across all 66 frames and 132 sides. Raw image-trace points were kept, as audit only.

The viewer's presentation was then split into three tiers:

[production geometry]  — solid colour, eligible for solids
[review aids]          — dimmed, filtered out in 3D
[dimension annotation] — dotted grey, separate toggle

None of this changed a single coordinate. It changed what could be seen and what could be named, and that is what stopped the recurrence.

7. Practical checklist — handing a drawing to an AI

• Split the layers first. With CAD, export the geometry layer alone; with only a raster, make two crops. Thirty minutes.
• Write the member dictionary — drawing vocabulary ↔ code name. Fourteen rows kill the round trips from "the shape at the bottom looks wrong", which had four candidates and was wrong about half the time. Compare the two instruction styles: "the current endpoint is probably right for r3; change r2's" named two members separately and moved in one pass. "the detail below is a mess" named nothing and cost a round trip.
• Give every region an authority in one word — "cell / as drawn / rule (what + how much)". Write it per property, not per part. Without the table, the R2 endpoint took three rounds; with it, the information needed was one sentence.
• Tag every number's provenance — Excel cell / drawing marking / derived rule / code default. The fourth, unmarked, produces ghost dimensions. Do it before someone asks you to reconcile against a source, not after.
• When marking up a screenshot, say in one word whether you mean the drawing or something the AI drew. Separate roles by role name, not colour. Two points 592 mm apart were the same red dot.
• Do not let "closed" mean "member" — state the test. The one that worked: "a shape generated with no dimension of its own, purely from other members' coordinates, is a construction aid." Supporting tests: three- or four-point closed shapes; edges matching a printed number exactly; bundles of evenly spaced parallel lines; and — the one that catches the subtlest case — a closed region containing 0% of the source edge points of the member it is named after.
• Ban the automatic closing chord. An open source chain must not be silently closed last-to-first. That single convenience turned an honest trace into a 320 mm invented edge and a "closed: true" report.
• Do not draw geometry alone — make it draw the dimension lines too. A free validator; that is how the 528 came out. A dimension line that collapses to a point is telling you the step it measures does not exist.
• Put the instruction's own conditions into the gate, and make visual inspection procedural. "0.0 mm dimension error" and "132/132 visual mismatch" can be true at once, and even p95 = 1.5 px is meaningless when input and marking scheme share a premise. Errors caught by an automated gate acting alone: zero. Visual comparison was the only detection path.
• Make missing evidence block, not pass. Stale, one-way, same-lineage or absent evidence must read as a blocking state, never as zero error — otherwise a missing input becomes a green light.
• Fix thresholds before you measure, and never move them afterwards. The 98% coverage bar was declared in advance and the result came in at 99.6%. Declared afterwards it would have proved nothing. Four separate documents in this project independently found it necessary to write down "do not weaken the validator to obtain a pass."

What I could not verify

• The utility opening conflict is half resolved. 132 of 132 sides disagree and the cell values were used. The question of whether the cells or the drawing govern was escalated and was answered — the cells govern, the drawing supplies topology. What has never been supplied is the anchor rule that would close the consequence: the recess is 217.7 wide against a cell that says 300.
• The "channel 100×500" marking — built, from a construction rule given on 14 July, but the member it stands for was never identified. The branch name in the code is the AI's invention.
• The 528 dimension collapses are diagnosed, not fixed. The cause is confirmed as a geometry builder producing a zero-width ledge; the geometry was not rebuilt.
• No Revit runtime proof exists. Every number in this post comes from the web viewer, the payload, or static reports. Whether any of it produces correct solids in Revit was never demonstrated — the evidence index records userVisualApproval = false, dynamoRuntimeProof = false, finalRelease = false.
• Side-detail raster holdouts stayed at 0/5 on both sides, and the whole-section holdouts at 0/8, throughout. These were never waived and never passed.
• The structural trace behind all 132-side gates comes from one section sheet, applied to all 66 frames. It is not a sweep of all 33.
• Not everything was under version control. One work plan notes plainly that a complete before/after diff is impossible because the work was not git-tracked.
• Suite-level state at last measurement: 60 validators, 36 exiting clean and 24 not. The failures are attributed to unchanged subsystems, but "attributed" is the correct word — they were not individually re-diagnosed.

What's next

Part 4 covers the other half: making the AI produce questions a human can settle in one word.

---

Tunnel automation series — nine parts.
← Previous: Dynamo Code Blocks and the Cost of 137 Hardcoded Values
Next: Human-in-the-Loop AI for BIM: Make It Ask, Not Guess →
Start of the series: Dynamo Built the Whole Tunnel and Never Read the Excel File