willtools-demo/docs/lift-check.md

Panel Lift Check

Select an assembly, click the inserts that carry each stage, choose where the HTML goes. One report per piece covering stripping, transportation and erection, ending in one recommended position per insert and the delta from where it is drawn.

Revit  ──liftexport──>  <mark>.job.json  ──panellift──>  <mark>.html
(IronPython 2.7)                          (CPython 3.9+)

The job file is kept beside the report. It is the complete input, so any number in the report can be re-run by hand, on a machine with no Revit on it:

python -m panellift WP000.job.json -o WP000.html --json

---

Three things the Revit side decides

None of them is mechanics, and all three are wrong by default if nobody decides them.

Which way up, and on which axis

x = 0 is the bottom of the piece as erected. Get it backwards and the erection stage drops the wrong row of lifters — tens of thousands of pound-feet, and it looks entirely normal in the output.

Read it off the assembly origin. Every piece carries one, drawn in the model as a red/green/blue triad, and it is a thing somebody placed with a direction rather than something inferred.

Inference is what got this wrong. Comparing the elevation of the two ends of the length axis answers it for a wall panel erected on end and is meaningless for a horizontal one, where both ends are at the same height and the "difference" is whatever the model's rounding happens to be. The anchors got assigned to whichever end won a coin toss.

Every panel direction is asked how much of itself points up, and the largest wins:

erected vertical axis	the top of the piece is	the anchors
length	an end	snap in x, pinned along the piece, free across it
width	a long edge	snap in y, pinned to that edge, free to slide along

Those are two different constraints and they are not the same inserts, so pinned and pinned_y are separate. Collapsing them into one flag gets one case wrong, and the wrong one is a recommendation to put an anchor where the piece has no edge.

If nothing points convincingly up (< 0.7, so more than 45° off), it refuses rather than guessing. So does a piece whose origin stands its thickness up: a beam idealisation spanning in the panel's own plane has no meaning for a piece stood on its face.

Which way the piece spans, per stage

A piece does not always hang the way it was cast, so the span is a property of the stage, not of the panel:

stage	spans
stripping, transportation	the long direction, always — that is how it lies flat, and how the face lifters are rowed across it
erection	whatever the assembly origin stands up

For a wall panel those are the same thing and nothing changes. For a horizontal panel erection spans the width, and the rows have to be taken again in that direction: the anchors along the top edge are one support when the piece is standing and several when it is flat.

The solver is not taught about orientation. The piece is turned instead — cli.transpose swaps length with width, every x with its y, and pinned with pinned_y — so the mechanics stay one implementation checked against published examples. Turning it twice gives back what you started with, which is a test.

The position search sits out any stage that spans the width: it optimises one set of coordinates, and a turned stage's x is the panel's y, so including it would be optimising against two different pieces. It still answers for the stages it can and names the one it left out — silently answering for two of three stages would read as an answer for all three.

Where an insert acts

A face lifter acts at the centre of its solid. An anchor cast into the top edge does not: it is welded to a bar, so its modelled box centre sits inboard by however long that bar is. On one real piece the gap was 7 inches, and 7 inches of lever arm on the erection pick is not a rounding error.

So handling.lifter_groups carries an at field:

handling:
  lifter_groups:
    face:
      families: [ANCHOR_FACE_4T]
      at: measured                 # where it is modelled
    edge_top:
      families: [ANCHOR_EDGE]
      at: top                      # acts at the end of the piece

at: top also implies the insert is pinned — it cannot be moved along the piece, because being at the top edge is the detail — and on_edge, which is what turns on the shear check below.

Which insert is what

Nothing in the code knows a part number. lifter_groups maps family-name substrings to roles, and the stages are written in terms of roles:

  stages:
    - {name: stripping,      pci_case: stripping,      strength: fci, groups: [face]}
    - {name: transportation, pci_case: transportation, strength: fc,  groups: [face]}
    - {name: erection,       pci_case: yard,           strength: fc,
       groups: [face, edge_top], exclude_top_rows: 1}

exclude_top_rows: 1 is the crane, not the panel: it cannot reach the topmost row of face lifters once the piece is being stood up, so erection hangs off the rows below plus the anchors at the top edge.

These are defaults, and only defaults. What a crane can actually reach on the day is not in the model.

Picking the inserts

The button temporarily isolates the piece in whatever view you are already in — not a view it picks for you, and never a new one — and asks you to click the inserts for each stage in turn. The defaults arrive pre-selected, so the usual answer is still one click, and only this piece's inserts are selectable, so a stray click cannot become a support line.

It used to be a checklist of rows, and that was wrong twice over. A row is the tool's guess about which inserts share a hook, and the label named one family when the row held two: one edge anchor and two face lifters an inch apart at the same station read as three edge anchors, the whole row was filtered out of stripping by the anchor's group, and the piece was analysed on six of its eight face lifters. Nobody can audit a checkbox that says 5'-8". Everybody can audit three inserts lit up on the piece in front of them.

stage_audit still reconciles the defaults against what the groups hold, but it now says rather than refuses: with a human clicking every insert, a bad default costs clicks instead of an answer. What it is telling you is that the highlighted defaults are not to be trusted on this piece.

The stage table in the output is followed by what was actually picked — families counted, and the stations they stand at. The numbers mean nothing without it, and it is the one part of the run that came from a person.

---

Prestress

A pretensioned panel is not the same piece as a reinforced one, and for a long time this checked it as though it were. On a real 8 in. panel the strands put 359 psi of precompression into the section against a stripping limit of 444 — leaving them out overstated every handling stress by that much, and turned a piece that passes at 70% into a FAIL at 102%.

The stress at a station is now four terms, not one:

f  =  -P/A                    precompression, everywhere
      -(M + P·ez)·cz / Iz     bending through the thickness
      -P·ey·cy / Iy           bending ACROSS the piece

evaluated at all four corners of the net section, tension positive.

The third term is the one that gets forgotten. Nothing applies it — it exists because the prestress is off-centre across the piece, which happens as soon as an opening cuts some strands and moves the section's own centroid the other way. On the panel above it is worth 146 psi of tension at one corner, a third of the budget.

Where the numbers come from

where the strands are	the model — this piece, and which ones a blockout crosses is a fact about geometry
how hard they were pulled	the design summary, as the per-strand I.T. figure Extract Design already reads into reinforcing.strand_groups[].it_lb
loss	design_assumptions.prestress_loss_pct in the project config, default 8%

Loss is a stated assumption, not a calculation. A time-dependent model needs an age, a humidity and a curing schedule none of this has, and a plausible-looking number from guessed inputs is worse than a figure an engineer can argue with. It sits at the top of the config file with its own comment because every point of it is worth about 4 psi of credited precompression — in the direction that makes a piece look safe.

When that assumption is the reason a piece passes

Cracking already warns when a stage lands within 10% of its tensile limit. When the piece also has prestress credited, that warning now says why it is worth a second look: the number rests on the assumed loss, not a calculated one, so a piece that only just squeaks by on an 8% guess is exactly the piece where the guess matters most. Re-running it somewhere loss is computed over time — the plant uses Eriksson Wall for that — has moved the answer before: one real piece came back 1.64% initial and 8.24% final, and 0.23% at the station that governed. No prestress credited, no such note — there is no loss assumption behind a bare-concrete number.

The band is the same 10% the cracking check already uses; this only adds words to a finding that already exists, and never changes OK to WARN or WARN to FAIL on its own.

A piece with strands in the model and no initial pull on its design is refused, not warned about. That is the whole point: the failure mode being fixed here was silent.

Transfer, and what a blockout does to a strand

A strand carries nothing where it stops and picks its force up over the transfer length, ACI 318's f_se·db/3, worked out from the pull actually on the design. That matters at both ends of the piece — the lifters nearest an end sit inside it — and at every opening, because an opening cuts every strand it passes over.

On the sample panel the opening spans 16 → 56.25 in. across, which is two of the six strand lines, so four of twelve strands are severed:

              Aps, in²
22.62 ft        1.84     full
25.11 ft        1.75     inside the transfer length of the cut
27.04 ft        1.33
27.50 ft        1.22     the opening starts; the four are gone

A strand that misses the opening carries straight through it untouched. A run shorter than two transfer lengths never reaches full force anywhere along it, which is the right answer and not an edge case: a strip of panel between two openings genuinely is not fully prestressed.

A pocket is not an opening — recesses, added 2026-09-01

All of the above is what a blockout means, and until 2026-09-01 the exporter called every rectangle it read a blockout. It reads them off the side faces of the concrete solid, and a blind pocket has side faces exactly like a hole does — so an 8 in corner pocket with 3.5 in of concrete behind it arrived here as a void through the thickness and cut fourteen strands passing a clear 3.5 in above and below it. That is where the last genuine-looking capacity FAIL on the reference sweep came from: M/φMn 1.04 a foot from the end of a piece whose model has no opening in it, and the owner's answer to the drawing was "那不是穿孔。。。没穿".

The through test had existed on the Revit side the whole time (liftexport.opening_penetration — shoot a line down the thickness axis through the rectangle's centre, intersect it with the solid, through when under 0.05 in of concrete is left) and simply was not wired into the export. It is now, in liftexport.split_openings:

blockouts	the through ones. Unchanged shape, unchanged meaning.
recesses	the blind ones — the same rectangle fields plus concrete_in (what is left along the centreline) and depth_in (thickness − that).

A rectangle whose penetration could not be solved stays in blockouts and the export says so in a problem line: could not tell is not blind, and the through reading is the one that takes section and strand away.

What this package does with a recess is nothing. It is read, carried on Panel.recesses, and counted in the piece summary — no section property and no development length moves for it, so every number on the page treats the pocket as solid concrete. That is unconservative over the pocket, and the report says so in a line of its own rather than leaving it to be discovered. Making it real means depth-aware section properties; that is engineering, not wiring.

The weight gate does read depth_in, because it has to: the reconstruction subtracts a pocket at its own depth now, where it used to subtract it at the full thickness and, for one day between the two, not at all.

When the piece spans its width

Strands are pulled along the bed, so they run the length. Stand a horizontal panel on its long edge and they are now across the span, where they precompress nothing that resists that bending. transpose drops them and the report says so. Rotating them into the new x would credit the piece with a compression it does not have — the one error here that makes a panel look safer than it is.

The check uses the full panel width for the section while the piece hangs from a handful of discrete inserts. That was worth checking and it holds: the path sideways to an anchor is a beam whose depth is the span dimension, so on a real 26.8 × 11.5 ft piece with 8 ft between anchors it costs 4.3 psi against 444 allowable. The arithmetic, and the one geometry where it needs redoing — a large opening cutting across the anchor line — are in docs/handoff.md.

Compression

Only worth checking once there is prestress, and then it is: 0.6 f'c, at all four corners, reported as CRUSH.

Checked against something else

Every number above is reproduced from an independent run of the same piece through a commercial wall-panel program — its inputs read off its own file, its outputs off its own report, neither consulted while this was written. Feeding its moment into this section gives 417.4 psi where it printed 417.6, and 667.5 psi of compression where it printed 667.4. test_prestress.py keeps those numbers.

What still differs, and deliberately: that program idealises stripping and transportation as a static lift (rigid supports, unequal reactions) while rig_mode here is per stage and the plant sets it. Transportation is now plant-configured dunnage when the plant says so: handling.dunnage.mode is lifter_rows or fraction, the stage carries supports instead of lifters, and the solve is a continuous beam on rigid supports with no sling or insert check. A plant that has not configured dunnage still gets the old lift path, and the report says that out loud.

A dunnage line under an opening

The plant's fraction rule places a support a fraction of the span in from each end, and it is blind to geometry. On one real piece that put a support at 5.23 ft on a panel whose opening ran 3.23 to 12.52 ft — a support line under a hole: the section modulus there was 464 in³ against roughly 1900 for the full section, and that stage came back at 1.14 of its limit.

The beam solve already uses the real section at every station, opening or not, so the arithmetic is not wrong. What is wrong is that nobody reading a line force or a stress ratio can tell a support is bearing where the concrete mostly is not, so every support on a dunnage stage is checked against section.voids_at() at its own station. When the missing width there is at least half the panel's full width — most of it, not a sliver — the finding names the support's position and the opening it falls inside. Severity WARN: the piece may genuinely be carried that way, and this does not say otherwise. It only says so.

---

Capacity, printed beside the demand

Added 2026-08-31, on the owner's instruction: "panellift, station table, 现在加入 pVn, pMn, Mcr, phi, 等等的数字。" Six columns on every station table, after the stress columns and before the note:

... f_t | f_c | allow | f_t/allow | Mcr, kip-ft | φ | φMn, kip-ft | M/φMn | φVn, kip | V/φVn | note

The first eight columns did not move, in position or in value. Measured: the 40 real job files rendered before and after this work produce pages that are byte-for-byte identical outside the station table, clock frozen.

A ratio over 1.0 is a FAIL, and the engineer stamps past it

They were informational for one day. On 2026-09-01 the owner ruled:

"M/pMn 对我而言>1.0是可以的,我能盖章。你不行,大于1.0你就报fail, 我做最后决策。"

(A ratio over 1.0 is acceptable to him — he can stamp it. Not to this tool: over 1.0, report a FAIL. He makes the final decision.)

So checks.check_capacity_ratios now imports capacity.py — the test that used to assert it could not is inverted in place — and raises:

FLEX-CAP	M/φMn > 1.0 → FAIL, naming the piece, the stage, the station, the ratio, and that φMn is strand only
SHEAR-CAP	V/φVn > 1.0 → FAIL, same rule

The doctrine is narrow and worth stating exactly: the tool may not bless a ratio over 1.0. It may not weigh the exceedance, discount it, or decide it does not count. Reporting is the whole of its job; the stamp is the engineer's.

Four things follow, and none of them is negotiable in the code:

• No development-length exclusion. Every exceedance measured sits within a strand's development length of a free end or an opening edge, where φMn — strand only — falls towards zero while Mcr does not. The owner was told that and ruled FAIL anyway. The finding still carries the sentence, with the embedment, the free end it is measured from and l_d, because that is what he decides on; it is context on a FAIL, never a reason to withhold one.
• The demand did not move. M and V are the analysis's own factored handling numbers — self weight times the PCI Table 8.3.1 multiplier and nothing else. Whether a strength-design load factor stacks on top was not answered and is still in Open.
• A dash is still not a verdict. A station that could not be judged prints its own reason and takes no part; where no station of a stage could be judged — a piece with no strand, so there is no φMn to be over — the check returns nothing at all, the way check_compression does when there is no prestress. That is the one silence it has, and the station table prints the reason at every row it applies to.
• The stress check is untouched and still carries its own verdict. Cracking and flexural capacity are two questions and neither replaces the other. On the reference sweep the stress-only verdicts are unchanged piece for piece: 111 OK, 59 WARN, 13 FAIL, 1 refused.

Every station, not the table's rows. The check scans all ~2000 stations of a stage, not the ~25 the station table prints. A verdict that moved with a display stride would be no verdict, and the difference is not academic: scanning every station finds a ratio over 1.0 on 112 of the 184 reference pieces where the printed rows alone find one on 40. Where a station over 1.0 would have been thinned away it is forced into the table with a worst M/phi-Mn tag — a verdict whose evidence is not on the page is a verdict nobody can check.

What it costs, and what it moved

Measured 2026-09-01 on the 184-piece reference sweep, one core, read + solve + every check, no position search:

before	37.0 s
after	79.3 s

The analysis half roughly doubles — about +0.23 s a piece, three stages of flexural capacity at every station — which is roughly +5 s on the eight-at-a-time batch path that measures ~31 s. profile_for computes the profile once per stage and the station table reads the same list, behind a fingerprint of the diagram it was measured on, so the page and the Checks table cannot disagree and a cache cannot outlive its numbers.

And the verdicts, on the same sweep:

	OK	WARN	FAIL	refused
stress checks alone	111	59	13	1
with the capacity ruling	53	13	117	1

104 pieces move to FAIL, and every one of them fails at an undeveloped strand. That is the ruling working as written, not a defect — but it is a much larger number than the four stations on two pieces the owner was shown when he made it (see the note under Open), and it is worth his eye before a batch goes out.

Mcr, and the two sevens that are not the same seven

Mcr = S·(fr + P/A) ∓ P·ez        fr = 7.5·λ·√f'c

fr is the code modulus of rupture, ACI 318-19 19.2.3.1. The handling tensile allowable on this plant is also 7.5√f'c — but that is a different quantity that happens to share a number:

pci.MODULUS_OF_RUPTURE_SQRT_FC = 7.5	a material property, ACI 19.2.3.1, no safety factor in it. It is what cracking means.
handling.tension_limit_sqrt_fc = 7.5 here	a choice between two schools the owner made on 2026-08-19: 5 = the rupture modulus over a 1.5 safety factor, 7.5 = the rupture modulus itself, no margin. A plant that picks 5 does not move the constant above it.

The constant carries that warning in pci.py, the report prints it under the table, and test_capacity.py fails if either half of the sentence goes away. The failure it is guarding against is somebody "unifying" them, which would silently move Mcr on every panel.

The sign follows the sense of M at the station. Strand below mid-depth raises the sagging Mcr and lowers the hogging one — on the test fixture that is 50,239 lb-ft against 14,239, a factor of 3.5. Absoluting it would have printed the sagging number at a hogging station.

What Mcr deliberately leaves out: the lateral prestress term (-P·ey·cy/Iy) that the four-corner stress carries. Mcr is a section quantity about one axis, which is how Eriksson prints it. So where a blockout has moved the prestress across the piece, a station can show f_t over the allowable with M under Mcr — two different questions, and the report says so rather than reconciling them into one number.

φMn is strand only, and that is checked rather than assumed

ACI 318-19 Eq. 20.3.2.3.1 — the approximate fps — with the equivalent rectangular stress block. The equation's (ω − ω') term for mild tension and compression steel is dropped, and the justification is not a belief about the concrete: model.Reinforcement is instantiated nowhere in this package, cli.read_panel has no field that could fill it, and the job file has no key for it. A panel reaching here has strand and nothing else. test_capacity.py asserts that, so the day liftexport can express a bar layer the test fails and the footnote has to be rewritten with it.

Why not strain compatibility, which PLAN.md has listed as the plan since 2026-08-18: it needs the strand's stress-strain curve, and no layer in this repository holds one. A curve assumed to make the answer look exact is a plausible-looking number from a guessed input — the failure this package exists to prevent. The approximate equation is code-sanctioned wherever fse ≥ 0.5 fpu (checked, and a station outside that range stands down with the reason rather than using the equation anyway), needs only what the job file already carries, and a reviewer can reproduce it on paper. Strain compatibility stays on PLAN.md as the upgrade.

φ is 0.90 where the section is tension-controlled (εt ≥ 0.005, ACI Table 21.2.2), computed from c at the station rather than stored as a constant somebody trusts. A station that is not tension-controlled prints a dash and its εt: ACI's transition between compression- and tension-controlled is not built, and 0.90 borrowed from the tension-controlled row would overstate the capacity of exactly the sections where it matters.

Transfer and development: one set of lengths, not two

Inside a strand's transfer and development length fps is reduced, and it is reduced from the lengths this package already had:

• lt is prestress.transfer_length_in — the same function the P/A columns use, honouring a job file that states one.
• ld = lt + (fps − fse)·db, ACI 318-19 25.4.8.1, whose first term is that transfer length. pci.development_length_in takes lt as an argument rather than recomputing fse·db/3, because two places computing a transfer length is how they come to disagree.

Available strand stress ramps linearly from zero at the free end to fse at lt and on to fps at ld. The free end is not only the end of the piece: a full-depth blockout cuts every strand it passes over, so the run restarts at each opening edge, reached through the same prestress.bonded_run the stress path uses. A strand standing in an opening carries nothing.

fse and fps saturate at different lengths and that is not an inconsistency. fse — the effective prestress — is fully in the concrete at lt, which is what a transfer length means, so Mcr stops growing there. fps — the stress at flexural failure — needs the longer ld. On the test fixture, at 40 in. from the end Mcr is already at its full value while φMn is still climbing.

A ratio that blows up near an end or an opening edge is the strand, not the piece. φMn is strand only, so inside a development length it falls towards zero while Mcr does not. On WP128's erection stage a station 3½ in. from a free end reads M = 1.9 kip-ft against φMn = 0.005 kip-ft — a ratio of 40,000%. That is arithmetic and it is true, and it is a statement about an undeveloped strand rather than about a section with no capacity. Such a row says so in its note, and φMn prints <0.1 rather than 0.0, because a zero in a capacity column is a number somebody divides by.

And since 2026-09-01 it is also a FAIL. The sentence above is the reason the owner needs the note; it is not a reason the tool may skip the verdict. He was shown exactly this row and ruled that the tool reports and he decides.

φVn is concrete alone

φVn = φ · 2·λ·√f'c · bw · d        φ = 0.75, ACI 318-19 Table 21.2.1

ACI 318-19 22.5.5.1 simplified. These panels carry no shear reinforcement in the handling direction, so Vn = Vc and there is no Vs to add — which is also why Eriksson's Vs Req and Av Min columns stay absent here rather than being printed as zero.

bw is the effective width at the station — the concrete actually there, openings removed, the same width S is taken on. d is dp, floored at 0.80h by ACI 318-19 22.5.2.2, which is the code's own provision for a prestressed member and is what carries a station whose strand is on the compression side or not yet developed. On an 8 in. panel with strand 1.75 in. up, dp is 6.25 in. sagging and 1.75 in. hogging; 0.80h = 6.4 in. is the floor under both.

Where every number's assumption is printed

λ is not hardcoded to 1.0. It comes off the concrete's own density, ACI 318-19 Table 19.2.4.1(a) — 1.0 above 135 pcf, 0.75 at or below 100, 0.0075·wc between. Every wall panel on the reference job is 150 pcf, so the answer is 1.0, but it is 1.0 because the concrete is normalweight and not because the code says so, and a lightweight piece is credited with less tension in Mcr and in φVn both.

The φ values, λ, β1, γp, the rupture coefficient and the shear coefficient are named constants in pci.py with their ACI clause beside each, never digits inside an expression. test_capacity.py walks capacity.py's AST and fails if any of them reappears as a literal. Proposed, not landed: they are code values, industry-wide, identifying nobody, so they belong in knowledge/catalogue.yaml as codes.aci318_19.phi.flexure_tension_controlled, codes.aci318_19.phi.shear, codes.aci318_19.modulus_of_rupture_sqrt_fc and codes.aci318_19.concrete_shear_sqrt_fc, each with the source: shape that file already uses. Landing them there needs a knowledge.py and a liftexport change — panellift has no YAML reader and is fed only by the job file — so the keys are named for routing and the constants stay in pci.py until somebody wires them.

Under the table the report prints, per stage: the fps method by clause, the transfer and development lengths and where they came from, the loss and that it is a stated assumption (design_assumptions.prestress_loss_pct, 8% by default), this stage's f'c — f'ci at release and stripping, f'c later — λ and the density it came from, fpu and its provenance, and the sentence that the ratio columns use the table's own M and V with no further strength-design load factor beyond the stage's PCI Table 8.3.1 multiplier.

fpu carries provenance, and audits itself

fps is written in terms of fpu, which nothing in the stress path needs — the precompression comes from the measured jacking force. The job file has no key for it today, so panel.prestress.fpu_ksi defaults to 270 and the report says, in words, that it is panellift's own default and that no layer stated one. That is the same treatment Stage.tension_limit_sqrt_fc gets, and for the same reason: a page that states a capacity with no way back to the grade behind it cannot be audited.

It is defensible as a default only because it is self-checking. The measured jacking stress fpi is printed beside it as a fraction of fpu — on the reference job that is 189.0 ksi, i.e. 0.700 fpu, which is exactly what the ticket legend says (0.70 fpu = 28.9 kips). A piece whose strand is really Grade 250 would show a jacking ratio above the 0.75 fpu limit and announce itself rather than hiding behind a plausible capacity.

The routing when somebody wires it: liftexport writes panel.prestress.fpu_ksi from spec.reinforcing.strand_groups[].grade_ksi, which designspec already reads off the design summary. Nothing writes it yet; cli.read_prestress reads it, and stamps fpu_source: 'job' when it is there.

A sandwich panel gains nothing from this

Insulated pieces refuse at cli._refuse_sandwich before any analysis runs, so they never reach a station table and there is nothing here for them. The sandwich report prints bounds, not stations, and no capacity column was added to it. That is not an oversight: a capacity for a partially composite section needs the connector data that PLAN.md's owner questions 5 and 6 are about, and the two geometric bounds do not bracket it. When the refusal is lifted, the capacity columns are one of the things that has to be answered for, not inherited.

---

The weight gate

Before anything is calculated, three weights have to agree within handling.weight_tolerance (2%). If they do not, the run refuses — no report, no numbers.

stated	the panel's own weight parameter
solid	every concrete solid the body draws × unit weight
reconstructed	(length × width × thickness − blockouts − recesses at their own depth) × unit weight

Which pair disagrees says what is wrong, and that is the point of carrying all three:

• stated vs solid — the model. A weight parameter that has not been recalculated, or a unit weight that is not what the piece is cast from.
• solid vs reconstructed — us. Those two describe the same concrete and differ only when the blockouts were read wrong.

That second one is why the gate is a refusal and not a warning. A missed opening makes the piece heavier, which sounds conservative and is not: the section modulus is then computed as if a door were not there, and that is the wrong number in the direction that says a panel is fine.

It has already caught one. Openings are read off the faces of the concrete solid, and any face reaching the panel boundary used to be discarded as "the outside of the piece". A door running down to the bottom edge has jambs that reach that edge — they were thrown away, the head clustered into a line, and the panel came back weighing what a solid one would. The test is now about shape rather than position: an outer face lies flat in one of the four bounding planes, so it is degenerate along one in-plane direction and sits at that direction's extreme. A jamb at some x strictly inside the piece is not that, however far it runs in y.

A void modelled as a separate family, a recess that is not full depth, and a non-rectangular opening will all still be read wrong — and will all still be caught here rather than reaching a report.

The solid was one solid, and a sandwich panel is not one solid

Measured 2026-08-31, and it is why this section changed. On the job's insulated panels the modelled-solid weight came out at about 65% of the printed weight, consistently:

piece	printed	the model's own weight parameter	modelled solid
WP115	18,573 lb	18,376 lb	11,983 lb
WP109	4,189 lb	—	2,880 lb

Two independent statements about the piece agreed with each other to about 1% and the solid sum was the outlier. The gate refused, correctly, on a number that was wrong — and because it refused, the entire handling analysis computed nothing on 27 pieces, 15 of them with issued tickets. Two rows of noise, 2.2 and 6.3, out of one cause.

The cause was one word. concrete_solid took the largest solid the body draws and called it the piece. That is right for an 8 in. solid panel, whose body draws one. A 16 in. insulated body draws several — concrete wythes with an insulation layer between them — and the largest of those is one wythe.

So the shape and the weight stopped being the same object:

• concrete_solid still returns the largest solid, and still answers the two questions that are about one prism: where the openings are (they are its side faces) and what the piece's extents are.
• concrete_volume answers the weight, by summing the solids — and by saying which ones it summed.

Which of them are concrete is decided by density, not by a product name. Structural concrete is 145–150 pcf normalweight and 110+ even lightweight; the board between the wythes is under 5. Nothing a wall panel is cast from lands in between, so a threshold anywhere in the middle separates them without anybody having to know what the plant buys. materials.concrete_min_pcf, default 50, and the density comes off the material's own structural asset rather than out of the code.

choose_concrete is the whole decision and it is pure — plain dicts in, plain dict out — so it is tested on host CPython with no model and no licence. The ladder, in order, and what each rung refuses to do:

what the body draws	what happens
one solid	that solid, unchanged — this is every solid panel in the job
several solids, all one material (or all with no material at all)	all of them. Nothing distinguishes them, so nothing may drop one. Where the material is unread the sentence says the weight is too heavy by whatever of it is not concrete
several materials, every one publishing a density	the ones at or above the threshold; the rest are named, with their volume, as left out
several materials, no density, but materials.concrete_names declared	classified by name — and it still refuses if any solid has no readable material name, because a solid nobody can name is not a solid that is not concrete
several materials, no density, no names declared	refuses, and names both wrong answers it declined: summing them all weighs the insulation, taking the largest drops a wythe

Nothing here asks what kind of panel it is. The classifier in knowledge.classify_panel is not consulted and does not need to be — the bug was never that the tool failed to recognise an insulated panel, it was that it counted one solid where the body drew several, which is a question about the geometry in front of it and not about the piece's type.

And the number never travels alone. source.solid_note in the job file says what went into the sum, source.solid_parts lists every solid with its material and volume and whether it was counted, and the gate's own report prints the sentence under the number: "summed 2 of the 3 solids the body draws as concrete: … Left out 6.20 ft³ — … — as not concrete (under 50 pcf)." Both wythes with the insulation left out is a different claim from 18,500 lb, and only one of the two can be argued with.

Whether the printed weight includes the insulation is not established here and is not guessed at. The sum's convention is stated rather than assumed: it is concrete only, and the insulation's volume and density are both printed beside it, so the difference is arithmetic anybody can do. At sandwich-board densities it is worth a fraction of a percent of the piece — inside the gate's 2% either way — so it does not decide whether a panel reconciles; it decides what the report is claiming.

No measured leg is no gate

A missing solid weight used to leave a silent hole: the gate fell back to stated against reconstructed, those two agreed — they are both built out of the same dimensions — and the piece passed a check that never ran. solid is the only one of the three read off the piece's own geometry, and solid-vs-reconstructed is the comparison that catches a blockout read wrong, which is the entire reason this is a refusal and not a warning. So a run that could not weigh the concrete now refuses and says which of the three was never read, rather than passing on the two that cannot disagree.

An insert is worth less at release

A catalogue rating is derived at one concrete strength, and the anchor pulls a cone of concrete out, so below that the capacity follows sqrt(f'c):

factor = min(1, sqrt(f'c actual / basis))

It does not rise above the basis — past there the anchor's own steel governs.

The consequence for the job file: ratings go out underated, with basis_fc_psi beside them. One report checks the same insert at release (stripping) and at 28 days (everything else), so a single pre-derated number would be wrong for all but one stage. panellift.checks.rated() applies it per stage, where there are tests.

On a 3500 psi basis, releasing at 2500 costs 15%. That is the difference between a lifter reading 72% and 85%.

---

The safety factor is the insert's, and 2.67 was nobody's

What a rating means, first. Every working_load_lb and shear_load_lb in knowledge/catalogue.yaml is a published safe working load — the factor is already inside the number — so the default reading applies no factor at all and dividing again would be a double count. tension_fos / shear_fos come into force only where a rating is an ultimate, which the caller declares with capacity_is_ultimate. Nothing in this repository sets that flag, so on every shipped path today the factors are not reached.

They were still wrong, and in the direction that passes an anchor. Until 2026-08-31 shear_fos was 2.67 — as a Rigging default, as a read_rigging default, as one file-wide catalogue.safety_factors entry, and as what liftexport wrote into every job file. No page published it. The comment justifying it as "the manufacturer's 4:1 tension / 2.67:1 shear" was written the day after the constant and cited nothing.

The one datasheet in this repository for the parts it reached — ALP catalog p53, 02/2024 — heads its capacity table "Capacity in Concrete 4:1 SWL", one heading spanning both the shear and the tension columns, and prints shear equal to tension on all seven QLPD rows. The manufacturer's shear factor is 4:1. What 2.67 would have computed:

QLPD4T5WG   32,000 lb ultimate / 2.67  =  11,985 lb allowed
            published SWL              =   8,000 lb

Half again the load the manufacturer permits, on an edge anchor, in shear.

The fix is per part, not a better global. Replacing 2.67 with 4.0 would be the same defect wearing the right number: the next manufacturer's insert would inherit a factor read off ALP's page. Evidence that this is not hypothetical is in the same file — QL589SPG publishes 4,010 lb shear against 7,690 lb tension, nothing like the 1:1 the QuikLift rows show. So:

• each ALP entry carries its own safety_factors: {tension_fos: 4.0, shear_fos: 4.0} with the page cited beside it;
• catalogue.safety_factors is null, with a written reason, and is read only as a fallback a plant may fill for hardware the catalogue does not cover;
• Lifter.tension_fos / Lifter.shear_fos carry the resolved number into the job file, per insert, and Rigging's pair is the fallback;
• an insert with no factor is not judged against an ultimate rating. check_insert_capacity raises INSERT-NO-FOS naming it, and never substitutes a number.

And the ultimate route is unconservative here even at 4:1. The page shades four of its seven rows and says the shading marks where the anchor's own mechanical capacity governs — so the printed SWL is the lesser of the 4:1 mechanical figure and what the concrete holds:

part	ultimate / 4	published SWL
QLPD4T3WG	8,000	6,257	+28%
QLPD4T4WG	8,000	7,200	+11%
QLPD8T6WG	16,000	11,019	+45%
QLPD8T7WG	16,000	14,640	+9%

The other three agree exactly. For these parts the published working load is the answer and the ultimate is provenance, not an input — which is a fact about the route, not about the factor, and it is why capacity_is_ultimate stays false. panellift/tests/test_safety_factors.py pins all of it.

Open, and the owner's: whether an insert from a manufacturer whose sheet this repository does not hold should keep any default factor, or stand down without one. The code stands down today. Nobody has asked him.

---

Erection is two conditions

They are separate questions and they share nothing, so they are asked separately.

1. The pick — panel flat

Face lifters and edge anchors together, load shared out by the beam solve. Which rating applies follows from how each insert is loaded in that position, not from what the insert is:

face lifter	the line pulls straight out of the face → tension
edge anchor	the panel is edge-on, the line pulls across the anchor → shear

On the hardware this was built for those two ratings differ by nearly a factor of two, in the direction that matters: checking an edge anchor against its tension rating here passes an anchor that would shear out. Reported as INSERT, with the rating named in every line.

2. Standing plumb — panel upright, anchors alone

The face lifters have let go. They are pointing sideways and carrying nothing. The whole piece hangs from the edge anchors, straight down, in tension.

So this ignores the rig, the sling angle, the beam and the load multiplier entirely: it is piece weight ÷ anchors, against the tension rating. There is no distribution question in a piece hanging straight down, which is exactly why putting it through the beam model would be the wrong answer dressed up as the right one. Reported as PLUMB.

A stage with no edge anchors — stripping, transportation — never stands the piece up, so it gets neither the shear treatment nor a plumb check, and no warning about their absence.

on_edge is stated by the model, not inferred from having a shear rating — face lifters have one of those too, and guessing would quietly run both wrong checks on them. A missing rating gets INSERT-UNRATED or PLUMB-UNRATED rather than silence.

---

Recommended positions

The half of the question that gets acted on. A verdict says whether the pick as drawn works; it does not say where to put the inserts instead, and doing that by hand is a search nobody has time for.

One answer for the piece, not one per stage

An insert is installed once and then has to survive every stage. Optimising the stages separately gives three different answers for the same hole. So the objective is the worst stage's utilisation — peak tension over what that stage allows — and not a stress in psi: stages run at different concrete strengths, and 450 psi at release is a different problem from 450 psi at 28 days.

x: an exhaustive coarse sweep, then refinement

Not PCI Figure 8.3.2's closed form. That holds for two support lines on a prismatic panel, and a panel with door openings is not prismatic — where the openings are, the optimum moves, which is the entire reason to solve it.

The coarse pass tries every combination of stations at 1 ft, and that is not caution. The objective is not convex and not even continuous: with rolling blocks the support lines are split into two cable groups at their widest gap, so moving one line past another's midpoint re-partitions the load in a jump.

Coordinate descent walks straight into that. Measured on a real three-line pick: it settled at 280 psi with two rows collapsed 1.6 ft apart, while a spread layout it never tried reached 130 psi.

Refinement afterwards is local, at 1 in. then 1/4 in., which is safe once the coarse answer has put every line in the right basin. The search never returns anything worse than the layout it was given.

The last several inches of the answer are not determined. The search accepts an improvement at 1e-9 on an objective that is good to perhaps 1 part in 10⁵, and the objective has several near-equal basins — so which basin the coarse sweep hands to the refinement is decided in digits the beam solve cannot resolve. Measured on 19 pieces: a perturbation at the objective's own accuracy moves a recommended station by up to 10 in. (34.75 in. on one piece of a wider sample), and the moved answer is as often better as worse.

Read Δx as "about here" — a direction and a magnitude, not a dimension. The full measurement, what it says about the un-landed banded solver, and what a fix looks like are in Speed → Not done: the banded solver.

y: geometry, and it says so

The beam model has no transverse mechanics at all. Two things are wanted and they conflict:

• spread — inserts near the edges of the available concrete, because a narrow pair lets the piece roll about the line between them;
• centred — the row's centroid on the width centreline, so it hangs level.

Spread wins. The as-drawn spacing is kept where the clear strip allows it and opened out to fill the strip where it does not — never pinched inwards, which is what a symmetry-first rule does and it produces pairs a foot apart on a ten foot panel.

Where the openings leave no strip straddling the centreline, the row goes where the concrete is and the eccentricity is reported in inches. That is a statement, not a calculation. Whether the piece twists, and whether it needs rigging for it, this model cannot answer.

Installability first

Every offered position is checked against the openings and the catalogue's minimum edge distance, with the clearance applied to blockout edges as well as panel edges — an insert near a hole has less concrete behind it than its rating assumes. A recommendation that cannot be installed is not a recommendation.

---

A stage that was not analysed

A stage can be switched off — "enabled": false on the stage in the job file, enabled: false on the spec in handling.stages — and it still appears in the report. That is the whole reason the flag exists. Deleting the stage from the list instead leaves no record that anybody meant to check it, and a stage missing from a report is read as a stage that passed. "Could not be checked" must never be mistaken for "checked and fine".

What it looks like:

• In the summary, which is the one part of the page that is always open: a box in the same row as the stages that ran, dashed rather than colour-striped, with the sentence "Erection analysis not performed." and the reason if the job file gave one (disabled_reason, or the stage's note). No ratio — not a percentage, not a zero, not even a dash where the others print 96%. A dash in a column of numbers gets scored as a number that came out small.
• In the summary table, a row saying not analysed across the numeric columns and NOT RUN in the result column.
• In the detail, its own collapsed disclosure in its place among the others, spelling out that no load was applied, no stress computed and no check run — so there is no result to pass or fail.

The overall verdict:

• A skipped stage never becomes a verdict, and never changes one. Nothing was measured; it cannot pass and it cannot fail. OK/WARN/FAIL still mean what they meant, and the CLI exit code is unchanged.
• What does change is the claim. "All checks satisfied" is a statement about the panel and it is false the moment a handling condition was not looked at. So the banner reads "All checks satisfied for the 2 stages analysed — 1 stage (erection) was not analysed. This report does not say whether it would pass", and carries a PARTIAL tag so the shape of the banner differs too, for the reader who takes in the colour and moves on. The JSON summary says the same thing in complete: false and not_run: [].

Two refusals around it:

• enabled must be a JSON true or false. "false" is truthy in Python, so coercing it would run the stage the author meant to switch off and never tell them; 0/1 are refused in the same spirit.
• A job where every stage is disabled is refused. A page of "not analysed" boxes and no numbers is not a report.

A disabled stage is otherwise not validated — its multiplier, f'c and pick list are never read. Refusing the job over a field nobody uses would make switching a stage off harder than deleting it, which pushes authors straight back to the thing that leaves no record.

The key is absent from every job file written before it existed, and absent means enabled: all 184 job files under a real sweep render byte-for-byte identically with the flag in place. The writer follows the same rule and emits enabled only when it is false.

---

When it will not answer

• Fewer than two support lines — not a pick.
• Every insert pinned — nothing to recommend.
• A stage naming an insert the panel does not have — a hard error, never a quietly smaller pick group. Analysing three picks where four were meant is unconservative and looks entirely normal.
• A stage with no multiplier and no pci_case — refused rather than defaulted to 1.0.
• Short/long above 0.75 — the panel spans two ways and a beam idealisation cannot represent it. It refuses instead of answering, because answering would look ordinary and be wrong. Short over long, not width over length: transpose swaps the two, and reading it as width/length meant a turned piece came back above 1.00 and was refused as "close to square" at 2.33 to 1. Turning a piece cannot change whether it is square.

Speed

This section is where the batch timings live, and there are two separate measurements below that are easy to mistake for one. Both are on the same 184-piece reference sweep and both are real; they measure different paths, so they do not have to agree:

	what ran	where the figures are
the CPython half alone	python -m panellift <job> -o out.html --json on the saved job files, one after another, no Revit	the table immediately below
the real batch path	the Panel Lift button, one CPython subprocess per piece, measured end to end	"What was done about it", further down

Quote the second when the question is "how long does a batch take", because that is the path a user is on. Quote the first only when the question is about the package on its own.

Two figures elsewhere in the tree restate these and are looser than what is here: panellift/src/panellift/cli.py's docstring says a 184-piece batch takes "41 minutes" with the search and "40 seconds" without, which pairs the sequential with-search run against the eight-at-a-time without-search one — the like-for-like sequential figure is 2.5 minutes. PanelLiftCheck/script.py restates the batch-path row correctly. Neither is the record; this section is. Correct the docstring when something else takes you into that file.

Measured 2026-08-30 across the 184-piece reference sweep, CPython half only (python -m panellift <job> -o out.html --json on real job files, run one after another on one core):

	s	%
the position search (layout.recommend)	12.6	93
everything else — read, analyse, every check, render, write, summarise	1.0	7
one piece, end to end	13.6

Worst piece 45–49 s. The whole sweep one after another: about 40 minutes, 39 of which is the search. With the search skipped, the same 184 pieces — full analysis, every check, every verdict, every report written — take 2 minutes in total, and 0.7 s of that is the median piece.

The two numbers this document used to give were wrong

It said a run was "about two seconds", and the comment on _MAX_COMBOS costed a candidate layout at about 1 ms. Both were left behind by the search itself: recommend now sweeps every stage of the piece at once, and one candidate layout costs 15 ms per stage, fifteen times the figure the budget was reasoned about with. On that arithmetic the _MAX_COMBOS ceiling of 40,000 layouts is not "a few seconds at worst", it is ten minutes a stage.

The ceiling is left where it is on purpose. It decides which pieces get a full search rather than a local improvement, which is an engineering judgement and not a performance one; what changes is that the comment beside it now says what a layout actually costs. Both figures are corrected in place.

Where the time goes inside the search

884 objective evaluations on the median piece, 15 ms each. About 76% of one evaluation is a single linalg.solve — dense Gaussian elimination, no dependencies, deliberately (see linalg.py). Every piece in the reference model has a stage with rig_mode: static, so that solve is in the inner loop for all 184 of them:

reduced system	248–268 dof (266 typical)
true half-bandwidth	3 — it is a beam, two dof a node, and only neighbouring nodes are coupled
diagonal spread, unscaled	3.5 × 10¹⁰ to 1.2 × 10¹¹

A dense O(n³) elimination on a matrix that is 98% zeros is the whole cost.

What was done about it

The search became optional, and a batch skips it. --no-recommend on the CLI, recommend_positions in the run-time options for the single-piece button (default ON — the recommendation is what the button is for), and always off in a batch. tools/sweep.py passes it too: that sweep reads the verdict, the per-stage ratios and the findings and never looked at a recommendation, so it was computing one and throwing it away 184 times.

Every stage is still analysed and every check still runs: the flag drops an answer, never a check. Measured across the whole reference sweep, the verdicts are unchanged piece for piece — 111 OK, 59 WARN, 13 FAIL, 1 refused, with and without.

Measured end to end through the real batch path (one CPython subprocess per piece, 184 pieces). These are the numbers to quote about a batch, and they are a few percent off the CPython-half table above because this path also pays for process start-up and file I/O per piece:

	one at a time	eight at a time
search on (what shipped)	38 min	8.9 min
search off	2.5 min	~31 s

The ~40 min / 2 min in the table at the top of this section is the same comparison measured on the package alone. Nothing disagrees; two paths were timed.

A report whose search did not run says so, in the warning style, under the heading the positions would have filled — on the HTML page, on the button's own output, and as "searched": false in the JSON summary. The section is never simply absent. It cannot be: the report's words for a search that ran and found nothing are "the inserts as drawn are already at the best position this search can find", and a page missing the section reads as exactly that. Same rule as a stage with enabled: false.

"searched" is written only when the search was skipped, the way the job writer emits enabled only when it is false. A summary without the key is a summary from a run that searched, which is what every summary written before the flag existed means.

A batch runs on several cores. Each job was already an isolated CPython subprocess reading one job file and writing its own report, log and summary — nothing shared, so running eight at once is a scheduling change and not a numerical one. min(cores − 2, 8), two cores left alone because Revit is open and the user is still working in it. Worth about 4.8× on the real batch path, as the table above shows; it is the belt to the flag's braces, and it is what keeps a batch tolerable for anyone who does want the positions.

The coordination is the risk, not the arithmetic, and batchrun.py is where it lives for a reason — read its header before touching it. The queue, the lock and the thread factory are created on the UI thread while the defining scope is alive, and every function a worker thread runs has its names bound as default parameters. There are now N threads that can kill Revit instead of one, so pump carries its own outer guard.

The search remembers layouts it has already costed. _peak_psi is pure for one frame — the frame holds the load profile, the section and the station list, none of which move when a pick moves — and about 17% of the calls in a real search are exact repeats: the coarse sweep and the first refinement pass cross the same stations, and each refinement sweep re-tries every line's current position before concluding it cannot improve on it. Measured 1.13× over the whole sweep (3717 s → 3300 s of CPU), and it cannot change an answer, because a memo hit returns the number the recomputation would have produced.

All 184 reference reports render byte for byte identically with the memo in and the flag absent, HTML and JSON summary both, clock frozen. That is the standard the enabled work set and it is the standard for anything that touches this search.

Two dead things came out with it: _Frame._spares, a field whose comment claimed a reuse optimisation that was never written, and a guard in _peak_psi that re-solved the section if "the station list changed under us". It could not fire — _make_frame builds that list from the same expression, the same profile and the same discontinuities diagram() does. A dead branch in the hottest loop in the package is a branch nobody can test.

Not done: the banded solver, and the reason it is not a speed question

The obvious next step is to stop running a dense O(n³) elimination on a matrix of half-bandwidth 3. A banded LDLᵀ measures 3.3× as a drop-in and about 7× with banded assembly, which would take a run from 13.6 s to near 4 s. The kernel is real and it works.

It is not landed, and the reason is not the kernel. Swapping solvers moved recommended stations by up to 2.25 in., and that was read as the banded solver being suspect. It is the wrong reading, and the measurement that shows why is below.

What was measured

Perturb the objective by a relative epsilon — a deterministic one, so it models a different but equally valid solver, one that rounds each layout the same way every time — then re-run the search, and judge every answer it produces with the unperturbed objective. Judging is one solve per layout, not a search, so it is cheap. 19 pieces of the reference sweep:

perturbation	pieces whose stations moved	worst move	the moved answer was
1e-9	0 of 19	—	—
1e-6	4 of 19	9.75 in.	better on 2, worse on 2
1e-5	4 of 19	10.0 in.	better on 2, worse on 2
1e-4	6 of 19	10.0 in.	better on 4, worse on 2

On a wider sample one piece moved 34.75 in. — nearly three feet — under a 1e-6 perturbation, and the layout it moved to was 12% better in governing utilisation than the one the shipped search returns.

What that means

The search is not noisy at its own tolerance. At 1e-9 — the threshold _sweep_objective accepts an improvement at — nothing moves at all, on any piece. The tolerance is not the problem.

It is unstable at the accuracy the objective actually has. The static solve is a dense elimination on an unscaled system: translational and rotational degrees of freedom sit in the same matrix, and its diagonal spans 8.4 × 10¹⁰. Elimination error goes as machine epsilon times the condition number, and the diagonal spread is a floor under the condition number, so the objective is good to something like 1 part in 10⁵ — squarely inside the band where the table above says the answer wanders.

And the wandering is not noise around one optimum. If it were, the moved answers would be equally good and the choice would not matter. They are not: some are better and some are worse, by up to 0.010 of utilisation. The objective has several near-equal basins, the exhaustive coarse sweep picks between them on digits the solve cannot resolve, and the local refinement then descends whichever one it was handed. Two pieces in nineteen have a layout about ten inches from the recommended one that is 7–11% better, and the search does not find it.

So the banded solver question is the wrong question

"The banded solver moves stations by 2.25 in." is not evidence that the banded solver is wrong. Half of such moves are improvements. The test that settles it is the one above and it costs a second a piece: run both solvers, then score both recommended layouts with one agreed objective. Whichever layout has the lower true utilisation is the better recommendation, whatever produced it. Nobody had run that, which is why the 2.25 in. looked like a reason to stop.

Landing the banded solver as a speed change would have buried all of this under a 3× and left the real finding — the recommendations as shipped today are not determined to better than several inches, and on some pieces are not the best available at all — undiscovered. That is a call for the owner, not a refactor to slip in beside a cache.

What a fix looks like

1. Scale the system before solving (non-dimensionalise the rotational dof, or solve in a normalised basis). This is worth doing on its own: it costs nothing and it is what makes the objective trustworthy enough to compare solvers at all.
2. Then land the banded solver, judged on the true objective rather than on whether it reproduces today's stations.
3. Give the refinement more than one starting basin, or keep the best few coarse layouts rather than only the winner — that is where the 7–11% on those two pieces is being lost.
4. Add a tie-break that prefers the station nearest the layout as drawn, so two layouts the model cannot tell apart never produce a move order. On a drawing this is the one that matters: an insert should not be asked to move ten inches for a stress difference nobody can measure.

Until then, read Δx as "about here". It is a good direction and a good magnitude; it is not a dimension.

The three redundancies that came out earlier

All of one kind — recomputing something that had not changed. Kept here because the same shape is where the next win will be:

diagram()	interpolated W and Q at stations where it already held them by index. 9.4M binary searches. Both lists are sorted, so they are now walked with one pointer.
stress_profile()	called moment_at(x) for every x in diagram.xs — a binary search for the number in the list beside the one being iterated. Now a zip.
the search	recomputed S(x) per candidate layout. The section belongs to the panel and the picks do not touch it, so it is solved once per stage.

The first two are in the shipped checks, not just the search: the test suite went from 6.3 s to 1.2 s on the same change.

The strips the beam pretends are rigid

Two places where the one-way beam solve leans on a support being a line when it is really a handful of discrete points, and the panel between those points has to carry its load sideways to reach one:

• EDGE-PATH — erection. A horizontal piece stands on its long edge and hangs from anchors dotted along the top; the strip between two of them is a beam whose depth is the erected span.
• ROW-FLEX — any flat pick (span == 'length'). Each support row is a few inserts spread across the width; the strip between two of them is a beam whose depth is the longitudinal concrete beside that row — the longer of the two adjacent segments. The load is the row's factored reaction spread over the width, uniform because uniform is what the idealisation it corrects assumed too.

Both are near-noise on solid panels — deep beams, so stiff the answer is not close — and both exist for the geometry that breaks them: an opening reaching across the support line and eating the web. EDGE-PATH loses its depth where an opening cuts in from the anchored edge; ROW-FLEX loses it where an opening sits beside the pick row, leaving a foot or two of web where nineteen had been. Same arithmetic rotated 90 degrees, same severity bands, same honesty rules: nothing to rate against says UNRATED instead of passing, and no section left never reads as a pass.

The web is the concrete beside the row, which is not the same question as how much of a hole lies on each side of it. An opening wholly outboard of the row leaves the inboard concrete untouched, and the strip spans on whichever side is deeper. Measuring instead to the hole's far face made a bigger hole through the row come out as a deeper web — monotonically backwards, and the reason test_a_bigger_hole_through_the_row_never_reads_as_a_deeper_web walks a hole from 1 ft to 8 ft and refuses to see the stress fall.

A strip is not one depth either. An opening pinches it over its own band of the width and leaves the rest at full depth, and where the pinch sits decides most of the answer: a strip between two inserts carries its largest moment at midspan and none at all at the inserts, so concrete missing beside an insert costs almost nothing. The strip is therefore cut at every opening edge and each band rated where its own moment peaks — midspan for a strip between inserts, the root for an overhang. Taking the smallest web anywhere and applying it to the whole strip reported 522 psi against 444 on a piece whose midspan is solid.

Three shapes are reported rather than rated, because rating them means inventing a number:

• ROW-FLEX-INTERRUPTED — an opening crosses the row inside the strip. There is no concrete beside the row in that band at all; the load travels around the hole and comes back, which is not a beam of any depth. Calling it a zero-depth FAIL would condemn a piece the model cannot speak about. 18 of the 184 pieces in the reference model hit this.
• ROW-FLEX-NOT-A-ROW, one insert — a support line holding a single insert has no strip between inserts: the width hangs off a point. Every instance in the reference model is one staggered row read as two, because its inserts sit further apart along the piece than handling.group_tolerance_ft.
• ROW-FLEX-NOT-A-ROW, uplift — a line whose reaction is negative is being pulled up, not carrying the piece down into its inserts. Taking abs() of it and rating a strip against the result is arithmetic on a number that means the opposite; it is also a signal about the beam solve, not about this check.

Those three guards took the reference model from 28 ROW-FLEX failures — the worst reporting 33,491 psi against 444 — to none, with the worst rated strip at 62% of allowable.

What neither answers: a piece squarish enough for the two directions to share the load — aspect ratio warns above short/long 0.50 and refuses above 0.75 — and partial-depth voids, which reduce no section property in this package.

An insulated panel is refused, and the refusal says how far wrong it would be

Landed 2026-08-31, and it closes a window that had been open for a few hours. Until that morning panellift had never once run on an insulated piece: the weight gate refused every one of them because the solid sum was a single wythe. That refusal was wrong about the weight and accidentally right about everything else, because the analysis behind it models the section as solid concrete at the envelope thickness — and a sandwich is not that.

So when the weight was fixed, the gate stopped refusing and started letting insulated pieces through to a section idealisation that is wrong in the optimistic direction. The owner:

"把夹芯板当实心算并不 conservative。因为 insulation 并不会 100% composite, 你忽视了中间的 composite ratio 的计算和可能出现的问题。这是一个 insulated panel design 的时候非常大的一个问题。"

panellift now refuses an insulated job — SANDWICH-SECTION, no report, no verdict, exit 2 — and it refuses upstream-independently: whether or not the weight gate let the piece past is not its business. If a sandwich job file reaches the package at all, this fires.

How it knows

source.solid_parts in the job file, which the exporter has written since the weight repair. The signal travels in the file and is never re-derived on the CPython side — the file is the boundary, and a second opinion about a model that process cannot see is a guess with a different accent. The ladder, and the only rung that may answer "solid":

what the file says	the answer
no solid_parts at all	could not tell. Never "solid". A hand-written file is the author's own statement and is taken as written; an exported one has carried the key since the repair, so a file without it belongs to a piece the weight gate refused anyway
one concrete solid, nothing left out	solid. Every solid panel in the reference job
anything left out as not concrete	sandwich — that is what the insulation is
two or more concrete solids, nothing left out	sandwich, conservatively. Nothing in the file can tell a wythe pair from a panel and a separately drawn ledge; over-refusing costs an answer, and the other way round prints a third of the real stress

What the refusal prints

A refusal that says only "no" is a refusal nobody can act on, so the section-property comparison — which is the reason — goes out with it. On the real 16 in. piece (4 in. architectural wythe, 4 in. EPS, 8 in. structural wythe, 64 in. of clear width):

	I, in⁴	governing S, in³
solid at the 16 in. envelope	21,845	2,731
fully composite	20,139	2,324
non-composite	3,072	768
structural wythe alone	2,731	683

The solid idealisation overstates the governing section modulus 3.56× against the non-composite bound and 1.18× against the fully composite one. Both above 1.0, which is the finding: a sandwich has a hole in the middle of its depth, so it is weaker than a solid piece of the same envelope however well the connectors work, and there is no reading under which treating it as solid is safe.

The page also carries the shear flow at the connector plane (q = VQ/I, 0.0847 lb per inch of span per pound of shear on this piece), each bound's assumption beside its numbers, what stands down, and the enumeration below.

The bounds are scaffolding, not the product

Two section states are computable from geometry alone, with no connector data at all: non-composite (ΣI of the wythes about their own axes) and fully composite (the transformed section about the sandwich's neutral axis). They bracket the real panel, and they are what can be said while the connector data is absent.

The partially composite middle is what insulated-panel design is actually about. It needs per-connector slip stiffness and capacity per failure mode, neither of which exists in any layer, so the report presents the bounds as an interim envelope with the missing computation named — never as the method.

What the two bounds do NOT bracket

Three quantities are bracketed. Everything else about a sandwich panel is not a bounds question, and reading a two-bound report as an envelope over all of it is the trap this list exists for.

• Bracketed: wythe flexural tension (worst non-composite) — with the trap that the inner face of a wythe changes sign between the bounds, so both faces of both wythes have to be read, not only the envelope faces; interface shear flow (worst fully composite); deflection (worst non-composite). Differential bowing is a service problem and is declared out of scope, not silently omitted.
• Not bracketed — connector force distribution. Both bounds are distribution-free: one puts zero on every connector, the other spreads demand smoothly as V(x). Partial interaction concentrates slip at the ends of each shear span, so a uniform-demand assumption understates the end connectors. The mean is reported and named as a mean.
• Not bracketed — connector normal (tension) demand. A flat pick hangs one wythe off the other in direct tension. Not an interface-shear question at all, and where the panel is designed non-composite it is likely the governing demand — which is why a capacity is wanted per failure mode and not as one number.
• Not bracketed — local flexure of the face wythe between connectors, and connector force at openings and pick points.
• Percent composite is not one number. The stiffness ratio and the strength ratio are different quantities in the trade's own methods, so any percentage printed says which one it is. Both stand down today: without connector stiffness a computed ratio is not hard, it is impossible.

The plant's own family description calls these pins non-composite. That is carried verbatim as evidence about design intent and nothing in the mechanics branches on it — partial action exists whatever the label says. It is with the owner, and his answer picks which bound the pass/fail line is drawn against; the report carries both either way.

Conventions chosen, why each is the conservative reading, and the owner-question list are in panellift/PLAN.md.

Open

• What depth the beam should use once the refusal is lifted. The weight counts both wythes and the section now knows they are two — but only well enough to refuse. thickness_in and the openings are still taken from the largest solid's extents (ticketqc.concrete_extents), which on a body drawing several solids is one wythe; the job file now carries source.envelope_thickness_in measured over every solid beside it, so the two are on the page rather than one being mistaken for the other. What the extent actually comes out as on a real insulated piece is still a live read nobody has taken, and whether a sandwich acting through its connectors should be idealised on the envelope, on one wythe, or on a bounded pair is the owner's. Neither is inferred and neither is guessed at. Still unmeasured as of 2026-08-31; the bounds are now computed for all three so it can be answered against numbers.

• Transverse equilibrium between the strips: EDGE-PATH and ROW-FLEX rate each path separately with full sections. A piece squarish enough that both paths carry load together is exactly what the aspect-ratio gate refuses or warns on; it is not solved here.

• Whether a capacity ratio should become a verdict — ANSWERED 2026-09-01, and one third of it is still open. The question was put in three parts. (a) Should a ratio ≥ 1.0 raise anything at all? and (b) should stations inside a development length be excluded? were both answered by the owner, by DM, verbatim:

  "M/pMn 对我而言>1.0是可以的,我能盖章。你不行,大于1.0你就报fail, 我做最后决策。"

  FAIL, and no exclusion. He was told first that all four known exceedances sat within a strand's development length of a free end or an opening edge, and ruled anyway: over 1.0 the tool reports a FAIL and he makes the final call. What shipped the same day: checks.check_capacity_ratios, FLEX-CAP and SHEAR-CAP findings at every station of every stage, the development-length sentence carried on the finding as context, the offending station forced into the station table, and the whole of it written up under Capacity, printed beside the demand above.

  (c) is still open. Whether the demand should carry a strength-design load factor — LECWall's 1.4, which Material.handling_load_factor holds and nothing applies — on top of the PCI Table 8.3.1 multiplier, or whether the multiplier is the whole of it, was not answered. The demand is therefore exactly what it was before the ruling, and the report says so on the page. Nothing is guessed at until he answers.

  One measurement to put in front of him. The three-part question was asked against "M/φMn reached 1.0 at 4 stations on 2 pieces" over 120 job files, with V/φVn never over 0.31. Re-measured on 2026-09-01 across the 184-file reference sweep, that does not reproduce: the ~25 printed rows per stage carry 70 exceedances on 40 pieces, and every station of every stage carries 323 on 112 pieces — every one of them at an undeveloped strand, and V/φVn still never over 0.35. The ruling is unchanged by that and was implemented as given; but the sweep now returns 117 FAIL where it returned 13, and he ruled on a number two orders of magnitude smaller. Which of the two counts is right has not been chased down — the earlier one is not reproducible from anything in the tree.

• Strain compatibility for φMn, which PLAN.md has listed since 2026-08-18. What landed is ACI's approximate fps (20.3.2.3.1), which is strand-only and code-limited to fse ≥ 0.5 fpu. The upgrade needs a strand stress-strain curve no layer holds, and mild steel the job file cannot express.

• fpu is defaulted, not read. 270 ksi with its provenance printed, and the routing key named above. One liftexport line closes it.

• Partial-depth blockouts are carried but do not reduce S, and so are the blind recesses the exporter now separates out — the page states that approximation, and closing it means depth-aware section properties.

• The 184 sweep job files predate the through-vs-blind split and were written from a model that has since diverged from the one open (see the source.model guard in tools/sweep.py). Every number in them that rests on a blockout has to be re-exported before it means anything; 164 of the 184 carry blockouts at all, and that is the upper bound on how many moved.