Field Tools

Before you use a number from this app

Basis — Site Visits

What this stores, and where

Projects, plan sets and sheet indexes are held on this device only. There is no server yet, nothing is uploaded, and nothing is backed up. A project that exists only on one phone is one lost phone away from gone — keep the source plan set in the project folder as always.

Storage is IndexedDB. iOS clears an origin's storage after roughly seven days unused unless the app has been added to the home screen; the Storage button on the Projects tab reports whether the browser has granted persistent storage, and it is worth checking before relying on a downloaded set in the field.

Sheet numbers are read, not known

On import, each sheet's name is taken from the best available source, in this order:

• PDF bookmarks — a set published from Bluebeam or Revit carries one per sheet, named deliberately. Nested bookmarks resolve to the deepest entry, so a sheet inside a discipline folder is named after the sheet, not the folder.
• Page labels, where a set defines them as sheet numbers. Usually absent, or just 1, 2, 3 — in which case they parse to nothing and are skipped.
• The title block text — the bottom-right 38 × 32 % of the page, largest text first. This is guesswork and is labelled as such: the block is not always in that corner, the number is not always the largest text, and CAD often emits each character as its own text run so the number never appears as an intact string.

Which source answered is shown against every sheet at import. A scanned or plotted-to-image sheet with no bookmark comes back unnamed rather than guessed at. Nothing is written to storage until the list has been confirmed.

Sheet geometry and positions

Positions on a sheet are stored as fractions of the page MediaBox in the page's unrotated orientation, together with the page rotation and the sheet revision they were placed against — never as pixels. Pixels do not survive a different device, a different zoom, or a re-plot.

Distances use the page dimensions in points rather than the normalised fractions, because x and y are fractions of different dimensions. Any measured length also requires a per-sheet scale calibration; an uncalibrated sheet reports no measurement rather than a plausible wrong one.

Revisions

Markups stay bound to the sheet revision they were made on. When a newer revision is imported they are not moved automatically — they are reported as sitting on a superseded sheet, to be carried forward deliberately.

Server location

Each project records where it lives on the office server. Any form is accepted — a mapped drive (Z:\Projects\24-118), a network path (\\10.0.0.20\Projects\24-118), or a server name. Formatting is tidied, nothing is refused.

The path is stored as text. Setting it does not make anything sync, and the app never reaches the server.

Tapping the path copies it rather than opening a file manager. It cannot open one: browsers refuse to follow a file:// link from a web page, and no API exists to open Explorer or the Files app at a location. Copy, then paste into Explorer's address bar.

The path will also be printed on the punchlist report, so a reader knows which project folder a walk belongs to, and will be offered as the save location for exports on desktop, where the browser can be granted access to a folder once.

Folders

Plan sets are grouped into folders, one per visit. A new folder is named for today's date in YYYY-MM-DD form so folders list in date order; a second folder on the same day gets (2), then (3). Renaming is free text, but two folders in a project cannot share a name — compared case-insensitively, because two folders differing only in capitals is a trap rather than a distinction.

Sheets imported before folders existed appear under Unfiled. Nothing is hidden because a feature arrived later than the data.

Each sheet in the index carries a menu to renumber it, rename it, or delete it. A hand-entered number is recorded as manual rather than as something read from the file.

What deleting removes

Deleting a project removes its records, its plan set files and its queued changes from this device, and reports how much was freed. Deleting a single sheet takes its comments, markups and photos with it — as the confirmation says — but keeps the plan set file as long as any other sheet still uses it, and drops the file once the last one is gone.

Both are local. When sync exists, freeing space on one device will never delete a project for anyone else.

How a sheet is drawn

A sheet is drawn in two layers. The whole sheet is rendered once at screen scale and stretched while you pan or pinch, so movement never exposes blank paper; when you stop, the visible area alone is re-rendered at full zoom and faded over the top.

Only the visible region is rasterised because a browser canvas has a hard area limit — about 16 megapixels on iOS, where exceeding it produces a blank sheet and no error. A 36 × 24 sheet at 4 × zoom would be roughly 107 megapixels, so rendering the whole page at working zoom is not possible at all. Where the limit is reached the render is softened rather than dropped.

Zoom is capped at 16 × the fit-to-screen scale. What you see is the PDF as published — no vector data is re-drawn, re-scaled or re-interpreted, so anything measured off a sheet is measured off the plotted geometry.

Markup: the pen and the finger

A stylus draws, always — there is no tool to select first. A finger navigates: drag to pan, two fingers to zoom, and a single tap drops a comment where you tapped.

This is also how palm rejection works. A hand resting on the glass registers as a touch, and touch never draws — no timing heuristics, and no rejected-palm strokes to undo afterwards.

A tapped comment is not saved until you save it. An accidental tap opens a panel you dismiss rather than leaving a mark on a drawing. An empty comment with no note and no photo is discarded on save for the same reason.

What a markup is, and what it is not

Strokes are stored as vector geometry over the sheet — never drawn into the PDF. The plan set on this device is byte-for-byte the file that was imported, and any export is a new document.

Ink scales with the paper, so a stroke keeps the size it was drawn relative to the sheet. Comment pins do not: they hold a constant size on screen so they stay tappable when the whole sheet is in view.

Pen strokes are simplified before they are stored, keeping every point within about 0.75 pt of the line you drew — below what the eye resolves, and typically 80 % fewer points. A stroke shorter than 2 pt is treated as a resting stylus and discarded rather than left as a speck.

Everything is bound to the sheet revision it was drawn on and does not move when a newer revision is imported.

Site visits, and the number in the bubble

Every comment records the local calendar day it was written on, stored once by the device that was there. Visits are then numbered by position: the earliest day anything was written is visit 1, the next distinct day is visit 2, and so on. Every comment from one walk therefore carries the same number, on the plans and in the log.

The day is local and is stored, not derived on reading. A comment written at 8 pm is already the next day in UTC, so deriving it from the timestamp would file half an evening walk under tomorrow — and would file it differently again for a reviewer in another timezone.

The number is derived rather than counted, because a counter would need a lock two offline phones cannot share. The consequence is that importing an older visit renumbers the ones after it. That is correct: it genuinely was the earlier visit all along.

The comment log

The Comments tab is every comment in the project, grouped by visit, one line each with its photos collapsed until the line is opened. This is the structure a report will be generated from, so the screen and the deliverable cannot drift apart.

A comment does not have to be on a drawing. Add comment records one with no sheet and no position — access, a submittal, something said on site — which previously had nowhere to go.

Photos

Photos attach to a comment, so every photo knows the sheet and the point on it that it belongs to, and the log can link back to that location. They are downscaled to 2000 px on the long edge at JPEG quality 0.80, with a thumbnail — enough to read a nameplate if the shot is framed, and about a tenth of the storage.

Re-encoding applies the camera's rotation flag and discards the rest of the EXIF block, including GPS. Location is therefore not recorded, which is the safer of the two defaults; if a walk needs it, that is a deliberate change rather than an oversight.

Zoom

The app's own zoom is disabled — pinching or double-tapping the interface scales nothing, because the sheet viewer does its own zooming and a header that scales out from under a drawing reads as a fault. Every control is at 16 px or larger so browser zoom is not needed to operate it.

Export

Two deliverables, both generated on the device with no signal. The visit is chosen first — a punch list that silently mixed three walks together would be worse than useless, because the reader has no way to tell it happened. The picker appears only when there is more than one visit; with one, the summary still names it.

Marked-up plan set (PDF)

Contains only the sheets carrying comments for that visit. A marina set is forty sheets and a walk touches six; issuing all forty makes the reviewer hunt, and hunting is how a finding gets missed. The selection comes from the same function that drives the comment counter on Docs, so what the badge says is on a sheet is exactly what the export puts in the file.

Pages are copied, not re-rendered — the page's own content streams, fonts and images come across untouched, so the drawing that comes out is the drawing that went in. Anything that re-rendered would be substituting this app's idea of the sheet for the sealed original.

Each comment becomes a real PDF text annotation at its pin: selectable, searchable, carrying author and date, and a contractor can reply to it in Bluebeam or Acrobat. A numbered bubble is also drawn into the page content, because an annotation is invisible on paper and in simpler phone viewers — so the printed set still reads. Photos ride along as embedded file attachments named V2-E-101-03-1.jpg, so the attachment panel sorts into the same order as the report.

Annotation text is written as UTF-16. The usual PDF string type cannot carry anything outside ASCII, and a field note routinely does — 90°, 3/4″, ±, an em dash. An earlier version dropped those characters silently, so 90° bend arrived as 90 bend.

A pin is stored as a fraction from the top-left; PDF user space counts from the bottom-left, in points, from the MediaBox origin — which is not always zero. Rotation needs no handling, and that is the payoff for storing pins in the page's native orientation: an annotation rectangle is also in unrotated space, so a pin on a /Rotate 90 sheet lands correctly for free.

Punch list report (Word)

The firm's letterhead is filled, not rebuilt. Its five horizontal rules are legacy VML shapes and its branding lives in the document body rather than a header part, so a rebuilt document would lose both. The .docx is opened as the zip it is, the tokens in word/document.xml are replaced, photos are added as media with their relationships, and the zip is written back.

Every token is a single contiguous run, collapsed offline once. Word splits text into runs at arbitrary boundaries, so a find-and-replace for a placeholder split across five runs matches nothing — silently, producing a report with the placeholder still printed on it. A missing token now fails the export rather than shipping.

Unlike the PDF, this includes every comment, including the ones not on a drawing. A note about access or a missing submittal has nothing to mark up but still belongs in the report. Photos are drawn at 4.2 in wide against the letterhead's 6.1 in usable width, aspect preserved, with their markup burned into that copy only — the stored photo stays clean.

Files are handed to the share sheet where the device has one, which on iOS is the only route to Files, Mail or Teams; elsewhere they download. pdf-lib (1.17.1) and fflate (0.8.3) are vendored alongside pdf.js for the same reason — a CDN is not there on a dock. Only fflate's synchronous API is used: the async half spawns a worker from a blob: URL, which this app's worker-src 'self' forbids.

Marking up a photo

Drawing has moved off the drawing and onto the photograph. The pen, eraser, ink colour, line width and undo used to be docked over the sheet viewer; they now live in the photo annotator, reached by tapping any saved photo on a comment.

The reason is trackability. A mark on a sheet carried no visit number, no author in the report and no place in the punch list — it could not be exported and could not be answered. A mark on the photograph says the thing only the photograph can, and it travels attached to the comment that explains it.

Both the finger and the pencil draw here, which is the opposite of the sheet viewer. On a sheet the finger had to navigate a 36×24 before anything could be marked, and the pen/finger split gave palm rejection for free. A photo fits the screen, so there is nothing to navigate and no reason to refuse a finger.

Markup is stored as vectors over the image, as fractions of the image width and height — never burned into the JPEG. Burning it in would re-encode the photograph on every edit, make the markup impossible to remove, and cap the report at phone resolution. Stored as vectors, the same numbers drive the thumbnail, the full-size view, and the print-resolution render a report will use.

Strokes live on the photo record rather than as records of their own. A photograph has one author by construction and is edited as a single object behind a Done button, so a forty-stroke markup queues one sync operation instead of forty. Sheet ink keeps its one-record-per-stroke model, because marks on a drawing are independent and may be by different people.

Snapshot from a drawing

Snapshot on a comment lets you drag a box on the sheet and attach that window as a photo. It is what a report usually wants: the detail from the drawing next to the photograph of what is wrong with it.

The selection is made in screen pixels and converted to page points before anything renders, then re-rendered from the PDF at 2.5× the on-screen size. Copying the pixels off the canvas instead would capture the blurry CSS-scaled base layer at phone resolution — fine on the phone that took it, unusable in print. A selection dragged past the edge crops at the paper rather than capturing margin.

Snapshots are marked sheet in the comment log so a reviewer never has to guess whether a picture is a photograph or a drawing.

Text on a sheet — withdrawn

Writing loose words onto a drawing has been removed. Tapping a sheet now has one outcome: a comment, which carries a visit number, photos and a place in the log that becomes the report. Sheet text carried none of that and could not be tracked, so the same observation recorded two ways would have gone into a deliverable only one way.

Any sheet text already written is still drawn, in place, and is not editable or movable. It was a field observation, and those are not deleted because a feature was withdrawn. Re-record anything that matters as a comment.

The tool dock

Docked to the right edge, over the sheet: pen, eraser, ink colour, line width and undo. The tool decides what the stylus does — a finger still pans and pinches regardless.

Line width is a slider whose travel is spread across the offered nib widths rather than across the raw number, because those span more than tenfold and a linear scale would spend most of its length on widths nobody can tell apart. The preview dot is drawn at the size the nib will actually be on screen at the current zoom.

The eraser

It removes whole strokes, not parts of them. Splitting a stroke at the erase point would change what a markup is — one authored gesture — and make the question "who drew this" meaningless halfway along a line.

Its reach is a fixed number of screen pixels converted to sheet units at the current zoom, so it stays about a fingertip wide however far in you are, and a thick line can be erased without hitting its exact centre. With the eraser selected a single finger also erases, since a phone has no stylus; two fingers still pan and zoom.

Sharpness

Markup is drawn in a vector layer whose window onto the sheet moves as you zoom, rather than being scaled as an image. That distinction is why a line stays crisp at any magnification: scaling stretches pixels, while re-aiming the window redraws the geometry at the screen's native resolution. The plan itself is a raster from the PDF and is re-rendered on the same principle when you stop moving.

Text boxes

Drag sheet text to move it; tap it to edit. The grip at its end resizes it — dragging down enlarges. Position is stored as a fraction of the sheet and size as a fraction of sheet width, so both survive a different device and any zoom.

Not yet built

Arrows, measurement and its scale calibration, the punch list and the report are still to come, as is any sync between devices. The eraser removes whole strokes only — there is no partial erase.

Third-party components

PDF reading uses Mozilla pdf.js (Apache 2.0), vendored into the app rather than loaded from a CDN so it works with no signal. Version recorded in vendor/pdfjs/VERSION.

Calculation basis — Mechanical

Psychrometrics

ASHRAE Handbook — Fundamentals, Ch. 1, Hyland & Wexler formulation. Saturation pressure by eq. 5 (over ice, below 32 °F) and eq. 6 (over water, 32–392 °F). Humidity ratio eq. 20/21, wet bulb eq. 33/34, dew point eq. 37/38, enthalpy eq. 30, specific volume eq. 26. Barometric pressure from the standard atmosphere, eq. 3.

Wet bulb reported is the thermodynamic wet bulb, solved iteratively. It differs slightly from a sling psychrometer reading.

Coil and process loads

Computed from actual mass flow — m = cfm / v using the entering specific volume — not the 4.5 and 1.08 standard-air shortcuts. At 80 °F/67 °F entering at sea level the true factors are 4.33 and 1.06, so the textbook shortcuts overstate capacity by about 3.7%. The gap widens with altitude and with entering temperature. The app shows the effective factors so you can see how far from standard air you actually are.

Duct

ASHRAE Handbook — Fundamentals, Ch. 21. Friction factor from the Colebrook-White implicit equation solved by bisection (not an explicit approximation). Absolute roughness values from Ch. 21 Table 1. Velocity pressure Pv = ρ(V/1097)², which reduces to (V/4005)² at 0.075 lb/ft³. Rectangular duct friction uses the circular equivalent diameter De = 1.30(ab)^0.625/(a+b)^0.25 with velocity taken from the actual cross-section.

Air density is computed for dry air at the entered temperature and elevation — the ASHRAE standard-air basis, which returns 0.0749 lb/ft³ at 70 °F and sea level. Humidity moves density only a few tenths of a percent across the normal supply-air range, and assuming a humidity would be an unstated guess, so the app does not. The density actually used is always displayed.

Fitting loss coefficients are typical values only. They are adequate for sizing a run in the field. They are not adequate for a design of record — use the ASHRAE Duct Fitting Database entry for the specific geometry.

Pipe

Darcy-Weisbach with Colebrook friction factor, water properties (density, kinematic viscosity, vapor pressure) interpolated against temperature from standard steam-table values. Hazen-Williams is offered as a cross-check and is only valid for water near 60 °F in the turbulent range — it will mislead you on hot water, glycol, and low-flow branches. Inside diameters are catalog nominal values; confirm against the specified product. Valve and fitting K values are typical; confirm against published Cv for balancing, control, and strainer components.

Fans and pumps

Affinity laws with speed exponents 1/2/3. Impeller trim uses exponents 1/2/3; a geometrically similar fan wheel family uses 3/2/5. Both degrade outside roughly 80–115% of the reference point, and the app says so.

Plumbing — domestic water and sanitary drain

Basis is the 2021 International Plumbing Code, not the older editions the firm's spreadsheets cite. Water supply fixture units from Table E103.3(2); demand from Table E103.3(3); drainage fixture units from Table 709.1; building drain and sewer capacity from Table 710.1(1). Confirm against the edition the AHJ has adopted and its local amendments — plumbing is one of the most heavily amended trades.

Cold + hot exceeds the total on purpose. Table E103.3(2) note (a) sets each branch at three-fourths of the fixture total, because the cold peak and the hot peak do not happen at the same instant. Each column is summed independently and the total column is never computed as cold + hot. This differs from the firm's existing spreadsheet, which computes its total column as qty × (cold + hot) — so app totals will read lower than that sheet for any fixture with both supplies.

Demand takes the next tabulated row at or above the load rather than interpolating, which is the conservative reading and matches the spreadsheet's lookup behaviour; the interpolated figure is computed too so the two can be compared. Loads below the first row of a column use that first row and say so; loads past the last row return nothing rather than extrapolating. The flushometer-valve column is not tabulated below 5 wsfu. Hot water piping always reads the flush-tank column, per that column's own note, because it serves no flushometer valves. Continuous flows — irrigation, cooling make-up — are added in gpm after the conversion, never as fixture units.

Pipe size is the smallest nominal size whose velocity stays within the entered ceiling (default 8 ft/s), using catalog inside diameters; the velocity actually achieved is always shown. This is the field shortcut, not the IPC Appendix E segmented-loss method — it does not look at available pressure, developed length, meter and backflow losses, or elevation. For a service of record, run the pressure budget. The firm's spreadsheet pairs its Hunter's-curve lookup with a fixed Type L copper size column; results here may differ by a size where that table's implied velocity differs from the ceiling you enter.

Sanitary sizes are reported at 1/2, 1/4 and 1/8 in./ft from Table 710.1(1), including note (a): any building drain serving a water closet is at least 3 in. Sizes below 3 in. are not tabulated at 1/8 in./ft at all. The 4 in. minimum building sewer and the "not over two water closets on 3 in." limit that the firm's legacy SBCCI-based sheet carried are not in current IPC Table 710.1(1); the app flags the 4 in. question rather than enforcing it. Fixture-unit counts here size building drains, sewers, and horizontal branches of the building drain — not stacks, which use Table 710.1(2), and not vents.

Fixtures marked "assumed" are not in the cited IPC table. Hose bibbs, ice machines, bar sinks, clinical sinks and low-flow urinals carry values brought over from the firm's spreadsheets under Table E103.3(2) note (a) and Table 709.2, which permit assigning an unlisted fixture by comparison with a listed one of similar flow and frequency, or by its drain/trap size. The commonly quoted 2.5 wsfu hose bibb is a UPC Table 610.3 value, not IPC. Those rows are engineering assumptions and the reviewing engineer confirms them; the app labels every one rather than hiding it.

Calculation basis — Electrical

Electrical — voltage drop

DC conductor resistance from NEC Chapter 9, Table 8 (uncoated and coated copper, aluminum; solid conductors only through 8 AWG, matching field practice under 310.106(A)). Ampacity from NEC Table 310.16 at the selected 60/75/90 °C column, 30 °C ambient, ≤3 current-carrying conductors — no 310.15(B)/(C) correction or adjustment factors are applied; apply those separately if they govern the actual installation. Voltage drop is Vdrop = R/ft × A × ft × multiplier, multiplier 2 for single phase (current travels out on one conductor and back on the other, so the drop sees twice the one-way resistance) or √3 for three phase (the 120° phase relationship between conductors reduces this from 2 to √3) — the standard 2 × K × I × D formula, matching the firm's SuperiorVDCalc workbook. Provide any two of wire size, distance, and amps and the third is solved for; providing all three checks the actual drop for a known run. The drop is reported in volts with the percentage of line voltage in parentheses, because the specification is written in percent.

Solving for size: ampacity first, then voltage drop

When the wire size is solved for, the smallest conductor whose Table 310.16 ampacity carries the load is found first, and the voltage-drop search starts from there. Voltage drop is a performance limit; ampacity is a safety limit, and a conductor can satisfy the first while violating the second — which is exactly what happens on a short, heavily loaded run, where almost any size clears the drop allowance. The result names which of the two governed.

Table 310.16 — edition, corrections, and what is still unconfirmed

The ampacity table in this app is the 2026 NEC (NFPA 70‑2026) edition of Table 310.16. The 2026 edition revised 310.5(A) so the minimum conductor size became 16 AWG copper, 14 AWG copper‑clad aluminum, or 12 AWG aluminum, and added Table 310.16 values for those. CCA is not modelled in this app, and only the long-standing 90 °C value is carried for 16 AWG copper — published sources disagree on its 60/75 °C figures, so those are left blank rather than guessed.

Four cells were corrected on 25 August 2026, three of which overstated ampacity:

Cell	Was	Now	Direction
14 AWG Cu, 60 °C	20	15	overstated by 33 %
12 AWG Cu, 60 °C	25	20	overstated by 25 %
12 AWG Al, 60 °C	20	15	overstated by 33 %
3 AWG Cu, 90 °C	110	115	understated

The first three shared one cause — the 75 °C figure duplicated into the 60 °C column — and were reachable from the voltage-drop screen's 60 °C option, so a 20 A load on #14 copper was returning a pass. Any voltage-drop or ampacity result produced by this app before v0.6.39 that used the 60 °C column should be rechecked. The 75 °C column, which is the default and the one the reference legends are built on, was correct throughout.

The suite now checks the entire 60 °C copper column cell by cell, plus three structural rules that hold across every row: ampacity rises strictly with temperature rating, aluminum is always below copper at the same size, and ampacity never falls as size rises. All three of the overstated cells violated the first rule, which is how a transcription error of this kind is caught without anyone having to think to spot-check that particular cell.

Eight cells remain unconfirmed. A secondary source disagrees with the value carried here and no printed copy was available to settle it. These are not silently trusted: selecting one produces a warning on the result, and it must be confirmed against a printed 2026 NEC before it reaches a stamped drawing.

Cell	This app	Source disagrees
1 AWG Cu, 90 °C	150	145
6 AWG Al, 90 °C	60	55
8 AWG Al, 60 °C	30	35
300 kcmil Al, 60 °C	190	195
300 kcmil Al, 90 °C	255	260
600 kcmil Cu, 60 °C	355	350
1500 kcmil Cu, 60 °C	520	525
2000 kcmil Cu, 60 °C	560	555

The result card also now states, on every calculation, that the ampacity shown is the raw table value with no 310.15(B) ambient correction and no 310.15(C) conduit-fill adjustment applied. That qualification used to live only on this page, while the calculator itself reported an unqualified pass.

Electrical — marina shore power load

Demand factor by total receptacle count per NEC Table 220.120 (2023 NEC). This citation was previously shown in this app as 555.12(B), which is the 2017 designation; the table became Table 555.6 in the 2020 NEC and Table 220.120 in the 2023 NEC. The bracket values are identical across all three editions, so no calculated result changed — only the reference. Cite the designation belonging to the edition the AHJ has adopted. Connected load: a 50A/125-250V receptacle counts at its full 50A nameplate rating. A 30A/125V single-pole receptacle counts at 15A, half its nameplate rating — a firm convention, confirmed for this app: the 50A receptacles are two-pole 240V loads that draw on both ungrounded conductors of the shared feeder, while a 30A/125V receptacle is single-pole and loads only one of the two conductors, so on a balanced multiwire feeder carrying both load types its contribution to either conductor is taken as half of nameplate. This assumption is specific to a shared 120/240V multiwire feeder mixing both receptacle types — confirm it still applies to the feeder configuration on the project before using the result. A metered installation (individual kWh submeter per slip, NEC 220.120 criteria) gets the 0.9 multiplier per the firm cheat sheet's note 2. General-use 20A/125V duplex receptacles are counted at 180 VA each (Table 220.14(I)) with the Table 220.44 demand factor (first 10 kVA at 100%, remainder at 50%). Pedestal lights are counted at 9 VA each ×1.25 continuous-load factor (210.19(A)/215.2). All electrical amp figures assume a 240V basis for the duplex/pedestal-light adders, matching the source workbook.

The "Capacity around this result" grid on the Marina tab is a sensitivity sweep, not a second calculation — every cell calls the same demand-load function above at a nearby qty50/qty30, the way the source workbook's "Demanded Load" sheet sweeps receptacle counts against Max Amps and conditionally formats the result. It is a window, not the full sheet: the "Range to check" field sets how many receptacles up or down from the current selection are shown on each axis (default ±2), and green/red mean the same over/under-capacity comparison against Max Amps as the pass/fail note above it, not an independent check.

Not included by design: AIC/available fault current rating and standard breaker-size selection are not implemented as calculators here — use the reference legends for conductor/conduit selection and confirm fault current and breaker selection against the project's actual utility/transformer data and the panel schedule.

Reference legends (service entrance, portable cable, and branch circuit/feeder tables) are transcribed from the firm's cheat sheet and cross-checked row by row against this app's own Table 310.16 data — see the validation suite, section 25. They are quick-reference only; the project's issued conductor/conduit schedule governs.

Electrical — grounding reference tables

NEC Table 250.122 (equipment grounding conductors) and NEC Table 250.66 (grounding electrode conductors) are transcribed reference tables, 2023 NEC, not calculators — the app does no grounding sizing of its own. Each was transcribed against two independent published sources and then cross-checked against this app's own NEC Chapter 9 Table 8 resistance data: for every row, the aluminum entry is verified to be within 25% of the copper entry's resistance per 1000 ft, which is the physical relationship both tables are built on and an independent check on the transcription rather than a restatement of it. See the validation suite, section 32.

Table 250.122 is truncated at 3000 A on purpose. Published transcriptions of the aluminum column disagree at the 4000/5000/6000 A rows (750 vs 800 kcmil, 1200 vs 1250 kcmil), and the disagreement was not resolvable without the printed code, so those rows were omitted rather than guessed. Nothing the firm designs approaches that range.

Neither table's adjustment rules are automated. In particular 250.122(B) — proportional upsizing of the EGC when the ungrounded conductors are increased for voltage drop — applies routinely to long pier feeders and must be applied by hand. The 250.66(A)/(B)/(C) caps for rod, concrete-encased and ground-ring electrodes likewise are stated as notes only.

Validation

The calculation engine ships with a test suite of 272 assertions checked against published reference values — ASHRAE psychrometric tables, the ASHRAE duct friction chart and equivalent-diameter tables, the Moody diagram, AHRI rating conditions, steam tables, copper tube and Schedule 40 friction tables, NEC Chapter 9 Table 8, Table 310.16, Table 250.122 and Table 250.66, IPC Tables E103.3(2), E103.3(3), 709.1 and 710.1(1), and NIST unit factors. Pipe results are cross-validated between Darcy-Weisbach and Hazen-Williams, which share no code; electrical reference legends are cross-validated against the app's own ampacity table; and the IPC fixture-unit transcription is cross-checked against Table E103.3(2)'s own three-fourths rule, which is an independent constraint on the numbers rather than a restatement of them.

Run it with node validation.test.mjs. Every assertion names its source. Treat a failing suite as a stop-work condition on this app, and re-run it after any change to engine.js.

Known limitations, stated plainly: no glycol or steam properties; no duct or pipe insulation heat gain; no acoustics; SMACNA pressure-class and gauge selection is not implemented; the psychrometric chart is drawn for the entered elevation only; electrical calculators assume the 2023 NEC article/table numbers cited above and do not check 310.15(B)/(C) correction/adjustment factors, conduit fill, or AIC/breaker sizing; and the plumbing tool sizes building drains and sewers only — no stacks (IPC Table 710.1(2)), no vents, no traps or trap arms, no grease or sand interceptors, no storm drainage, and no Appendix E pressure budget for the water service.

About