How StructSuite Works: The Engineering Assumptions Behind Every Number

Every piece of structural design software makes hundreds of decisions its users never see: what to assume when an input is blank, which edition and which table a value comes from, what a footnote does to a result, which products made it into the database and which did not. Most tools keep those decisions private. We think an engineer should be able to audit their tools the same way a plan checker audits a calc package — so this page is the public register of StructSuite's engineering assumptions, written as the questions we asked ourselves while building it.

Every answer below describes the shipped software, not an aspiration. Where a decision traces to a specific code sentence, the section is cited; where it traces to engineering judgment, we say so and explain the judgment. If you find a decision you disagree with, that is exactly the conversation this page exists to start.

#Guards, not fallbacks: the rule everything else follows

#Why does StructSuite stop with a red error instead of assuming a default?

Because a silent default is a design decision made without the engineer of record. StructSuite's engines follow one rule everywhere: when a required input is blank or a judgment call is unmade, the calculation refuses to run — the step shows a red "required" line naming exactly what is missing, and the verification step will not produce results. The engines never substitute a "reasonable" number.

The distinction we draw is between three kinds of values:

Concrete examples from the shipped engines: the retaining wall module throws "no default unit weights are assumed" rather than assuming soil at 120 pcf; the wind module refuses to compute pressures until you classify the enclosure — "No default GC_pi is assumed" — rather than quietly using ±0.18; the wood beam engine refuses to verify anything if one psf-mode load item lacks a tributary width, because guarding only that combination would silently drop it while the dead-load-only combinations verified green.

#Has StructSuite always been this strict? What did the hidden-fallback audit find?

No — we got there by auditing ourselves. In August 2026 we swept the entire app specifically hunting silent fallbacks and found eleven. The honest highlights:

• The seismic module, with S_D1 still blank, used to fall back to C_u = 1.7 (the loosest period cap) and let the Eq. 12.8-5 floor produce a C_s from a missing input. Today nothing downstream of S_D1 computes until it is entered.
• The wood column module carried a hardcoded F_c⊥ = 625 psi for LVL/LSL/PSL bearing. Today, if a product's report publishes no F_c⊥, the module says plainly: "Bearing: not evaluated — no F_c⊥ published for this product; verify bearing per the manufacturer's ICC-ES report." It declines to check rather than fake a value.
• A column with the buckling factor unselected once reported "D/C 0.000 — PASS". A shear wall with a blank wall height once reported hold-down "T = 0 — PASS". A beam with a blank tributary width once assumed 2 ft. All three now stop and ask.

Every finding was fixed the same week, and the fixes are locked by tests. We publish this list because "we audited ourselves and here is what we found" is worth more than "trust us."

#Does StructSuite round intermediate values?

Never in the math. Stored state and every calculation carry full precision; rounding is purely a display-layer concern (values typically display to two decimals while idle, and inputs show your raw keystrokes while you type). This means the printed derivation you read may show 5.400 + 1.500 = 6.900 while the engine carried nine more digits — the displayed numbers are truncated views of the real ones, never the operands of the next step. No compounding round-off, ever.

#How do I know the printed report matches what I saw on screen?

Because they are the same thing. The printed calculation package renders the same component nodes the on-screen step summaries render — there is no parallel "print version" that could drift. That single-source rule is enforced by a contract test whose own header says why it exists: "If these break, the printed report silently drifts from the on-screen module." The report's table of contents is held to the same standard: TOC page numbers are measured against the real printed pagination at US-Letter paper width and guarded by an audit script, so the number printed in the TOC is the page the section actually starts on.

#How do I know the diagrams match the design checks?

Because they are the same analysis, not two analyses that agree. The shear, moment and deflection diagrams the beam module draws are rendered from the same solver result the Step 6 check tables were decided on — the figure reads that result, it never re-runs the analysis. The contract test asserts object identity, not equality, and the distinction is the whole point: equality is exactly what a second, independently written solver pass would also satisfy right up until the day it quietly stopped. There is one deliberate exception, and the code marks it as one: the sidebar's individual load cases ("Dead load (D)", "Live load (L)") are solved for the figure, because no design check verifies an unfactored single load type — there is no result to read, and nothing else in the report depends on them.

For a while, that was not true, and one number disagreed. The solver computes deflection at the reference E; the design deflection is taken at the adjusted E′ = E·C_M·C_t·C_i (NDS 2024 §3.5), plus the mandatory shear-deformation term for I-joists (§7.4.5) and for structural composite lumber. The check applied both. The figure, running its own pass, applied neither. On a dry, normal-temperature sawn or glulam beam the two are identical and nothing was visible — which is precisely why it survived: the common case hid it. On a wet, elevated-temperature or incised member, and on every I-joist and SCL beam, the diagram reported a smaller deflection than the check governing that same beam. The figure now plots δ at E′, says so in the panel heading, and states the shear component it cannot honestly draw — that term is a per-span closed form, not a curve — instead of leaving it out. We publish this for the same reason we published the rafter-table bug below: a figure disagreeing with the table beside it is exactly the kind of thing an engineer deserves to know their tools have had, found, and pinned against.

#How do I know a published guide matches the software?

Every number in a StructSuite worked-example guide is produced by running the shipped engine — not by hand transcription — and then pinned: each published example carries a verification test suite asserting the exact published values against the engine, and the production build fails if a published example guide has no pin suite. When an engine is revised, the pins fail, and the rule is to re-issue the guide, never to adjust the test. One guide takes this further: the beam formulas companion is generated from the finite-element engine rather than written at all.

#Code tables: verbatim, footnotes and all

#How are code and standard tables reproduced in the app?

As book-faithful replicas: same rows, same values, same footnote numbering as the printed table, rendered as selectable tables rather than hidden lookups. When two source documents tabulate the same physical thing differently, we reproduce both and never "unify" them (see the soil-table question below). Where a table was digitized from a source document, the source workbook or PDF is archived in the project's reference set, and representative cells are locked by regression tests.

#What happens when a table footnote applies to my design?

It is never applied silently. The standard layout everywhere a footnote can modify a value: the reference table, then always-visible checkboxes for the footnotes that involve a choice, then the entire verbatim footnote text in a collapsible — numbered exactly as the book numbers them. When a footnote is auto-applied because the code mandates it, the derivation says so in-line: the shear wall module's specific-gravity factor prints "taken as 1.000 (footnote 3: the Specific Gravity Adjustment Factor shall not be greater than 1)" right in the calculation, and the rafter tables print their footnotes verbatim in the result box the moment one fires (more on those below).

#What if two codes disagree — like IBC Table 1610.1 vs ASCE 7-22 Table 3.2-1?

They genuinely do: for several backfill classes the IBC and ASCE 7-22 tabulate different design lateral soil loads (well-graded gravel: 30 vs 35 psf/ft active; clayey sand: 60 vs 85). StructSuite's answer is to show both tables verbatim, let you select the row from the book that governs your jurisdiction, and record which you chose — with the hierarchy stated on screen: the IBC table values are minimums unless determined otherwise by a geotechnical investigation, which supersedes either book. What we refuse to do is average them, pick one silently, or present a merged table that exists in no code.

#Retaining walls: seismic earth pressure and the FEMA P-750 story

#Where do the seismic earth-pressure methods come from — are they printed in ASCE 7-22?

No — and that surprised us enough to chase the paper trail to its end. ASCE 7-22 §11.8.3 requires seismic lateral earth pressures for SDC D–F walls retaining more than 6 ft but does not specify a method; its commentary (C11.8) defers to the 2009 NEHRP Recommended Seismic Provisions (FEMA P-750) Part 3, Resource Paper RP 12. So we put the actual FEMA P-750 document in the project's reference set and verified every implemented equation against it, page by page:

• The Seed-Whitman simplified increment — ΔK_AE = (3/4)·k_h and ΔP_AE = (3/8)·γ·H²·k_h — is printed verbatim as RP 12 Eqs. 6–7 (p. 356). The module cites that page.
• The 0.6H application height of the dynamic increment ("inverted trapezoidal pressure distribution") is printed on p. 356 and repeated on p. 358. RP 12 never prints the trapezoid's ordinates; the 1.6/0.4 split StructSuite draws is the unique linear distribution with its centroid at 0.6H — the guide shows the two-line derivation.
• The Mononobe-Okabe closed-form K_AE is not printed in RP 12 at all. RP 12 prints only the thrust equation P_AE = ½·γ·H²·(1 − k_v)·K_AE (Eq. 4, p. 355) and defers the coefficient formulation to the soil-dynamics literature (Prakash; Das; Kramer; Ebeling & Morrison). So StructSuite cites RP 12 for what RP 12 prints, and cites "geotechnical literature — see module guide" for the closed form. It would have been easy to stamp "per ASCE 7-22" on all of it. It would also have been wrong.

The full derivation with live numbers is in the retaining wall design guide.

#Why does StructSuite block Seed-Whitman for clayey backfill?

Because RP 12 says to, and because the software often knows your soil. RP 12 p. 356 attaches a hard scope statement to the simplified method: "If soil conditions behind the wall have a cohesive soil component (i.e., a c-φ soil), this simplified approach is no longer appropriate."

Here is the interesting design problem: whether the module can enforce that depends on what it knows about your backfill.

The principle: hard gate where the class is known, advisory where it isn't — we can't gate on what we don't know, and pretending we can would be its own kind of silent assumption. When you selected your lateral soil load from a code table, the module knows the USCS symbol, and a letter "C" in that symbol means a clay fraction; a stated applicability limit plus known soil is not a judgment call, so the module enforces it. When your lateral load came from a geotechnical report's equivalent fluid pressure, the class never entered the software — so it tells you what to confirm instead of guessing.

#How does the retaining wall module handle sloped backfill?

As geometry it computes, plus a pressure value it refuses to guess. The backfill slope β is a Step 1 input (2026-08-22): the module raises the stability pressure plane at the heel edge to H′ = H_retained + t_f + L_heel·tanβ, adds the triangular soil wedge above the heel to the resisting weights and to the heel's design load, runs the seismic increment over the same taller height, and feeds the same β into Mononobe-Okabe — one wall has one slope. What it will not do is take the design pressure from IBC Table 1610.1 or ASCE 7-22 Table 3.2-1 for a sloped wall: those are level-backfill active/at-rest values (Terzaghi and Peck — ASCE 7-22 C3.2.1), and both codes route the site-specific condition to the geotechnical investigation (IBC §1610.1 → §1803). Declare a slope and the tables are guarded off with an error that says exactly that — the equivalent fluid pressure must be the report's value for the sloped condition. Seed-Whitman refuses a sloped wall outright (RP 12 p. 356: "not applicable for sloping ground above the wall"); the thrust's slope-parallel vertical component is conservatively neglected; and global stability of the backslope itself stays a geotechnical evaluation, stated in the design notes rather than silently skipped.

#What k_h does the software use — and can the geotechnical report override it?

For a cantilever concrete retaining wall — a yielding wall per ASCE 7-22 §15.6.1 — the default is k_h = S_DS/2.5, the design-earthquake PGA in the absence of a site-specific study per ASCE 7-22 C11.8.3. (That value is not in RP 12, which predates S_DS mapping and works in peak-ground-acceleration terms — another citation we keep separated on purpose.)

The geotechnical report can override the value — but not the judgment. You must answer the wall-restraint question (free to displace vs restrained) in every path; a k_h override supplies the number, never the answer to whether your wall yields. Restrained (nonyielding) walls have no built-in k_h at all in the current version: rigid-wall pressure models are geotechnical-input-only, and the module says so rather than quietly applying a yielding-wall coefficient to a basement-like wall.

#What else do the computed seismic methods assume?

Stated in the derivation itself, so a reviewer reads them without asking: dry, cohesionless backfill with groundwater below the base of the wall (RP 12 pp. 355–356, 359 — saturated backfill belongs to the geotechnical report); k_v = 0, because vertical shaking enters the strength combinations separately as E_v = 0.2·S_DS·D and a k_v inside the coefficient would double-count it; walls taller than 15 ft get an advisory citing RP 12's special-studies suggestion; and wall self-weight inertia (k_h × the concrete weights, the Richards & Elms formulation) is an explicit opt-in that, when selected, enters every seismic check — stability, bearing, and the stem's own strength check alike.

#Why do the stability checks show a factor of safety while the strength checks show D/C with a load combination?

Because IBC 1807.2.3 treats them differently, and the summary preserves each check's own code language. Overturning, sliding, and bearing stability are exempted from the §1605 load combinations by the code itself: they run at 1.0 × nominal loads (0.7 × nominal earthquake where included) against a hard factor of safety — 1.5 static, 1.1 seismic — with the investigated case named in parentheses (that's why the surcharge appears as "lateral only": it pushes, but its vertical weight is excluded from the resisting side per §1807.2.3). The concrete strength checks run the real factored combinations and report D/C exactly like the other modules, with the governing combination named on each row — 1.2D + 1.6H + 1.6L vs 0.9D + 1.6H for the toe envelope, the §2.3.6 pair for the seismic checks, and "≡" where the stem's lack of a dead-load effect makes the two combinations identical. The verification summary groups the two kinds under their own headings — Stability (FS at 1.0 × nominal loads), Member strength (D/C with the governing combination), Detailing — so each check appears exactly once, in its own language. The two framings still reconcile numerically: internally a stability step carries a D/C defined as required FS ÷ computed FS (that is how the module ranks governing checks), so an FS of 1.09 against a required 1.1 and a D/C of 1.01 are the same statement.

#Is the surcharge D, H, or L in the load combinations?

None of them — because StructSuite classifies effects, not loads. A surcharge (say 100 psf of parking behind the wall) is one physical load with two separate effects on the structure, and each gets its own letter:

Which column your surcharge belongs to is a judgment the code cannot make from a psf value — so the module asks: whenever a surcharge is entered, a required variable-or-permanent selection appears (unselected until you answer, like every judgment in the app), and the entire calculation re-letters the vertical effect accordingly — a permanent surcharge's weight folds into the dead-load table, resists overturning, and receives E_v in the seismic combinations, while the combination names themselves drop the L term.

The rule: vertical effects are classified by permanence — the backfill's own weight is dead load, the removable surcharge's weight is live load — while lateral effects are all H, and that is not an interpretation but the letter of the symbol list. ASCE 7-22 §2.2 defines it verbatim: "H = Load due to lateral earth pressure (including lateral earth pressure from fixed or moving surcharge loads), ground water pressure, or pressure of bulk materials." The parenthetical exists precisely for this question. The surcharge mirrors the backfill exactly, one permanence class down: weight → L instead of D, push → H either way. It is never part of D.

Two places the split shows its teeth. In the stability checks, IBC §1807.2.3's variable-loads-at-zero investigation means the surcharge pushes but doesn't hold: its lateral component drives the overturning while its vertical weight is refused as resistance — that is what "(lateral only)" means in the stability case names. And in the seismic combinations, where L drops to 1.0 but H stays at 1.6, the §2.2 classification is exactly what keeps the surcharge's push at 1.6 (stated in the stem-strength derivation) — in the static combinations calling it L would change nothing numerically, so the definition matters precisely where it does the most good.

#What safety factors apply to a retaining wall during an earthquake?

The static stability checks keep their FS ≥ 1.5; when earthquake loads are included, sliding and overturning are checked at FS ≥ 1.1 with 0.7 × the nominal earthquake load, per the IBC §1807.2.3 exception. Seismic soil bearing uses the ASD combination with the geotechnical report's transient-increase factor — the presumptive one-third increase is not assumed; if your report grants no increase, the check runs at the plain allowable. Concrete strength design of the stem, heel, and toe runs the ASCE 7-22 §2.3.6 seismic combinations with E_h and E_v.

#Wood members: what's in the NDS Supplement tables — and what isn't

#Which NDS Supplement tables are implemented?

The material step of the wood beam and column modules is one shared component, so both modules read the same digitized tables (each built from the per-table source workbooks and locked by tests):

The 5A/5B split between modules is a real material decision, not a UI whim: 5A layups put the strong laminations at the outer fibers for bending; 5B grades laminations uniformly for axial stress — so a pure column is not offered a bending-optimized layup. Deeper treatment: the NDS Supplement guide's 5A-vs-5B FAQ.

#Which tables are deliberately NOT implemented — and why?

• 4E (decking): no decking design exists yet; a pair of forward-looking factor helpers sit in the code with zero call sites, waiting for the feature.
• 4F/4G (non-North-American and multi-species groups): rarely specified where the common species cover the work.
• 5C/5D (hardwood glulam): U.S. structural glulam is overwhelmingly softwood.
• 6A/6B (round timber piles and poles): round columns are handled instead by NDS 3.7.3's equivalent-square method on sawn-lumber values (that option is currently not exposed in the UI, with the code intact behind a flag).
• 4C (MSR/MEL) is the interesting one: fully implemented — data, footnote-2 resolution of F_v/F_c⊥/G by base species, the whole path — and then deliberately hidden behind a one-line comment, to keep the selection focused on what engineers hand-pick (MSR/MEL is largely a truss-plant product). We hide by commenting out, never by deleting, so a decision can be reversed by restoring one line.

#How does StructSuite design 1× boards (members thinner than 2×)?

Through the only code-sanctioned path: NDS Supplement Table 4A/4B footnote 2, which lets a stress-rated board (nominal 1", 1¼", 1½" thick, 2" and wider) use the 2"–4" design values for its species and grade. The module makes that footnote a gate you must affirm: until you check "graded under the stress-rated board provisions," the board sizes stay grayed out. Three factors — C_F, C_fu, C_r — are locked at 1.00 for boards because each is tabulated only for 2"–4" material and each is an increase factor there, so declining them is conservative by inspection; the assumption is printed in the calculation and the report. Southern Pine users also get the SPIB grade map (IND 55 → No. 1, IND 45 → No. 2, IND 26 → No. 3). Worked details: the NDS guide's board FAQ.

#Why does switching between dimension lumber and timbers clear my species selection?

Because the same species and grade has different design values in different size classes (DF-L No. 2: F_b = 900 psi as dimension lumber in 4A, 875 psi as a Beam & Stringer in 4D — and within 4D, Beams & Stringers vs Posts & Timbers differ by up to ~37.5%). When a selection crosses the dimension/timber boundary, StructSuite clears the now-orphaned choice and flags it red-required rather than silently remapping you to the "equivalent" row of the other table. A red field you must re-answer is annoying for three seconds; a silent remap is a wrong F_b forever.

#Why can a different load combination govern bearing than bending and shear?

Short version: the load-duration factor C_D scales F_b and F_v per combination, but F_c⊥ gets no C_D at all — so the combination ranking changes when the capacity side stops moving. The full illustrated answer, with the D/C bar panels, lives in the NDS guide.

#Engineered wood products: what's included, what's excluded, and why

#Which manufactured products can I design with — and where does every number come from?

Sawn lumber and glulam come from the NDS Supplement. Everything else comes from the manufacturer's ICC-ES evaluation report — never from a generic "LVL" number — and every EWP design prints its own source ("Reference design values per ESR-1387") so a reviewer can check the same document:

Two honest subtleties. I-joists are never checked with grade-level F_b/F_v/E — their capacity checks use the report's tabulated moment and shear capacities per size and the tabulated EI, exactly as the reports intend. And the column module offers no I-joists at all, for the plainest possible reason: the reports publish no F_c for them, and we don't invent one.

#What was excluded or parked — and why?

Georgia-Pacific GPI I-joists are parked (data intact, not selectable): GP sold its engineered-lumber business to Boise Cascade in 2016 and the APA report (PR-L276) was withdrawn — we archive the last public revision for reference but won't offer a discontinued product as a design choice. Roseburg RigidLam (ESR-1210) and Pacific Woodtech PWT LVL (ESR-2909) are listed as reference-only in the resources directory, not selectable — each added product line is a curation and verification commitment, and we only ship lines we have audited. Why LVL has two brands while LSL and PSL have one: answered in the NDS guide.

#How were the manufacturer values verified?

By a dedicated audit against the archived report PDFs, which found and fixed real errors — including our own:

• BCI series mismatch: the app had been carrying the 1.5"-flange series' moment/EI columns under the 1.31"-flange series names; corrected to the true ESR-1336 Table 2 columns (moments dropped ~10–12%; shear was identical because it is web-governed).
• Versa-Lam E_min had been scaled from true E; ESR-1040 footnote 8 requires it from apparent E per NDS Appendix D — recomputed per grade (it had been 2.4–5.0% high).
• SCL volume factor C_v had never been applied; now applied per product with each report's own exponent and cap, with the correct simultaneity rule against C_L.
• Shear deflection is now mandatory wherever the reports require it — per-size coefficients for I-joists from each report's own formula, and the explicit 28.8wL²/(E′bd) term for LVL/LSL/PSL, shown as its own line in the deflection calc.

Every audited value is locked by a tripwire test suite whose stated purpose is that any "helpful edit" regressing an audited number fails the build. One thing this audit did not cover, and we say so: the framing module's TJI span tables (digitized from Weyerhaeuser's TJ-4000 workbooks and Trus Joist TB-805/TB-824) are on the verification roadmap but have not yet had their cell-by-cell pass — the beam-module TJI design values are audited and pinned regardless, because they come from ESR-1153, a different source.

#Framing: the IBC span tables, footnote by footnote

#How are the IBC 2024 rafter and ceiling-joist tables implemented?

As complete replicas — all six rafter tables, IBC 2024 Tables 2308.11.2(1)–(6), and both ceiling-joist tables, 2308.11.1(1)–(2) — digitized cell-for-cell from the ICC digital codes viewer with the code's verbatim ft-in values, every spacing block (12/16/19.2/24 in. o.c.), both dead-load columns, all four species and grades. There is deliberately no interpolation: every table axis is a radio constrained to exactly the values the code tabulates, the only free entry is your span, and a span beyond the (possibly adjusted) tabulated value returns an explicit FAIL naming the table. Members the prescriptive tables can't cover route to the TJI basis or to the full NDS beam module. (Readers on other editions: IBC 2024 renumbered these from the 2308.7.x you may know.)

#How is "span" measured in the rafter tables?

Along the horizontal projection of the rafter — not the sloped length — and the module says so in three places: on the span input, in the summary label, and in the result ("Maximum span (table, horizontal projection)"), with an expandable diagram. This is the convention every IBC and manufacturer roof table is written on; if you have ever wondered what happens when someone uses the sloped length instead, the hip rafter worked example quantifies exactly that mistake.

#What does the ceiling-attachment question actually do?

The rafter tables assume the ceiling joists (or equivalent rafter ties) sit at the bottom of the attic space, resisting the rafters' outward thrust at the plate. StructSuite surfaces that assumption as a mandatory question, quoting it in full — never as a silent default. Answer "no" — your ties sit higher — and the module opens IBC Table 2308.11.2(7): the tabulated span gets multiplied by the H_C/H_R adjustment factor (1/3 → 0.67 … 1/7.5 or less → 1.00), floored to the whole inch, with the full derivation row printed: table span × factor = allowable. Separately, "ceiling attached to rafters" vs "not attached" selects entirely different table data (L/Δ 240 vs 180 deflection basis) — a stricter dataset, not a factor.

#What happens when the table prints a footnote instead of a span?

Some cells of the IBC tables print a footnote marker instead of a number, meaning the tabulated span would exceed the table's 26-ft scope. StructSuite stores those cells as what they are — no invented number — displays "> 26 ft 0 in.", and conservatively caps the allowable at 26 ft, printing the footnote verbatim plus a treatment paragraph explaining the cap. If an H_C/H_R factor applies on top, the factor multiplies the 26-ft scope and the result reports the numeric adjusted cap. Two smaller notes are honored the same visible way: spans over 20 ft print the code's lumber-availability caution, and the floor-joist tables' 2-inch end-bearing footnote is auto-applied and echoed into the summary and the report.

#You got this wrong once — what was the rafter-table bug?

For a while, the rafter lookup served the 12-in.-o.c. data block for all four spacings, and the attached-ceiling path served the not-attached table's data. Consequence: 16/19.2/24-in. rafter checks ran against the longer 12-in. spans — unconservative. Concrete example: DF-L No. 2 2×8 at 16 in. o.c. was being allowed 21 ft 0 in. where the true table value is 18 ft 2 in. (The floor and ceiling-joist tables were never affected — their spacing blocks were always distinct.) The fix was to digitize all six tables in full rather than patch the lookup, lock representative cells across both formerly broken dimensions with regression pins, and browser-verify that a case the old data passed now fails. We publish this because a span-table bug is exactly the kind of thing engineers deserve to know their tools have had, found, and permanently pinned against.

#Shear walls: the plan distributes, each line designs, the base connects

#How does the shear wall module distribute story shear to wall lines?

You draw the building in Step 1 — a rectangular grid, checked bays for the footprint, checked grid segments for the shear walls — and the story force is distributed to the wall lines by the flexible-diaphragm tributary method, the wood-frame default. From there the plan drives the design: pick a line of resistance under the plan and Steps 2–6 design that line, with its wall lengths, openings, and end offsets all derived from the drawing (only the wall height is typed). Every line keeps its own selections — sheathing, hold-downs, end posts, base transfer — and switching the dropdown saves one line's record and restores the other's. A status list shows each line's governing shear check so the critical line is never hidden behind whichever one is open, and "apply this line's selections to all lines" copies the selections only: every line is still checked against its own share, walls, and height.

#Why do wind and seismic split differently across the same walls?

Because they are different physics, and a single "share of V" would be wrong for one of them. Seismic force comes from mass, which for a uniform floor is proportional to tributary area; wind comes from pressure on the projected face, proportional to tributary length along the span. On a rectangular plan the two agree. On anything else they don't: for the L-shaped plan in the sample project (a 60×30 ft body with a 30×20 ft wing), the three east–west wall lines take 37.5% / 50% / 12.5% of the seismic story force but 30% / 50% / 20% of the wind — the shallow wing band carries 60% more of the wind than of the seismic. Those splits are computed by the same engine that draws the plan (they are regression-pinned in the verification suite), and the module always distributes both cases so each line carries an E share and a W share; the governing combination is decided line by line, never by assuming one case controls.

#What connects the wall to the structure below — and where do those numbers come from?

Substep 4D designs the base shear transfer to the wall line's governing unit shear. On a concrete foundation it checks sill-plate anchor bolts: the wood-side value is Z_∥ from NDS 2024 Table 12E (sawn lumber to concrete, digitized in full and cell-verified) with C_D = 1.6 and the applicable wet-service and geometry factors, alongside the prescriptive floors — IBC 2308.7.1's 1/2-inch, 6-ft-o.c., 7-inch-embedment minimums and SDPWS 4.3.6.4.3's 0.229″×3″×3″ plate washers. The concrete side (ACI 318-25 Chapter 17 breakout and seismic provisions) is stated as a limitation, not silently assumed. Over wood framing it checks Simpson A34/A35/LTP4/LTP5 framing clips from the C-C-2026 catalog table (p. 310) — only the rows whose tabulated load direction is in-plane shear parallel to the wall, using the (160) column that the catalog assigns to wind and seismic with no further increase, and applying footnote 3's over-sheathing reductions as an explicit selection rather than a default. The module also enforces the reason this substep exists: in Seismic Design Categories D–F, SDPWS 4.1.10 bars toe-nailed connections from transferring seismic unit shears above 150 plf (ASD) — above that, a mechanical connection is the code path.

#Seismic loads: the height and mass are yours; the code path is ours

#How does the seismic module determine h_n — and what about gable roofs?

The module never asks for h_n directly: you enter the story table (each story's height and weight), and h_n is computed as the sum of story heights — on screen it reads "h_n = structural height as defined in Section 11.2 (sum of story heights h_sx)." That h_n then feeds T_a = C_t·h_n^x (Eq. 12.8-8, with C_t and x auto-mapped from your Table 12.2-1 system selection — wood shear walls land on the "all other systems" row) and the Table 12.2-1 structural height limit check for your SDC.

The gable-roof judgment — does h_n stop at the ceiling, the mean roof height, or the ridge? — is yours, and the seismic worked example resolves it through ASCE 7-22 §11.2: with a flat ceiling acting as the top diaphragm, h_n stops at the ceiling (20 ft in the example, not the 27.5-ft ridge); with a cathedral ceiling, the roof sheathing is the top diaphragm and h_n is the mean roof height; it is never the ridge. The example also shows why the answer barely moves the base shear on the spectral plateau — but moves every story-force lever arm when the mass rises with the diaphragm.

#How is the effective seismic weight assembled — does the software do the takeoff?

Honestly: no. You enter w_x per level, and the module deliberately does not automate the mass takeoff — no assembly builder, no slope factor, no tributary-wall splitter. The judgment of where mass lands is the part of an ELF run that most needs an engineer, so instead of hiding it we published the full method in the worked example: roof dead load taken on the sloped surface and converted to plan area (×1.118 for 6:12), gable-end attic triangles, walls split tributary half-up/half-down between levels, partitions likewise — landing at a roof level heavier than the floor (45,300 vs 35,800 lb in the example house), which surprises people and drives 72% of the base shear into the roof diaphragm. The takeoff section walks every pound.

#What does the module compute for diaphragms?

F_px per ASCE 7-22 §12.10.1.1 — Eq. 12.10-1 with the 0.2·S_DS·I_e·w_px floor and 0.4·S_DS·I_e·w_px cap — taking w_px equal to the story weight you entered. In the worked example the floor governs both diaphragms; skipping that check would have under-designed the second-floor diaphragm by 30%. Why F_px ≠ F_x, and when the minimum governs, is its own FAQ in the seismic guide.

#Where to go next

• See the philosophy applied end-to-end with live numbers: the retaining wall, hip rafter, glulam balcony, tall wood column, seismic base shear, and wind load worked examples — every published number engine-run and pinned.
• The NDS Supplement guide for the wood-tables deep dive this page only summarizes, and the resources directory for the source documents themselves.
• Or just open a module — retaining wall, wood beam, rafters & joists, seismic loads — and watch the red required lines ask you the questions this page explained.