BS 7671 inspections: bespoke editors
Some compliance jobs aren't a check-sheet; they're a structured test report with a fixed regulatory format. EICR, EIC and MEIWC (BS 7671:2018+A4:2026) all have a defined IET model layout, mandated columns, and a Schedule of Inspection straight from Appendix 6. concorbit ships a purpose-built editor for each: proper tables, every column the paper form expects, and the resulting branded PDF clients (and building-control officers) actually accept.
This is different from generic on-site forms (kitchen-sink check sheets) which still go through the Form Builder. BS 7671 is treated as a separate first-class flow.
How it works end-to-end
Operator creates a JobType called "EICR". Under On-site form / inspection they pick BS 7671 — EICR (Electrical Installation Condition Report) from the Compliance inspections group. Save.
Dispatcher creates a job of that type. concorbit auto-attaches an empty draft inspection in the background: no Form blueprint behind it, just a structured payload.
Engineer opens the job → clicks Open inspection →. The bespoke EICR editor opens with six tabs:
1. Client & installation: client/occupier, reason for the report, premises type, age, extent + limitations.
2. Supply & earthing: supply system (TN-S / TN-C-S / TT / IT), nominal voltage, Ipf, Ze, supply protective device, earthing conductor, main bonding (water/gas/oil/steel/lightning), main switch.
3. Schedule of inspection: proper 3-column table covering the full BS 7671 Appendix 6 item list (50+ checks for residential ≤100 A). Tap a code (✓ / C1 / C2 / C3 / FI / N/V / LIM / N/A) per row. Coded findings (C1-C3 / FI / LIM) prompt for an inline comment.
4. Distribution boards & circuits: add one card per DB (with reference, location, Zdb, Ipf, polarity confirmations, test-instrument serial numbers). Each DB has its own circuits table, a horizontal-scroll spreadsheet with all 25 columns from the IET Schedule of Circuit Details + Test Results: circuit number, description, wiring type, ref method, OCPD type/rating/breaking capacity, max permitted Zs, RCD type/IΔn, R1+R2, insulation L-L / L-E, polarity, measured Zs, RCD disconnection time, test-button checks, remarks, Pass/C1/C2/C3/FI result. Add as many circuits per DB as needed; + Add circuit at the bottom of each DB's table; × / ⧉ to remove or duplicate a row.
5. Observations: table for coded findings cross-referenced to Schedule item numbers (4.13, 5.12, etc.). One row per coded observation: code (C1-C3/FI), location, description, recommendation.
6. Summary & declaration: general condition, Satisfactory / Unsatisfactory rating, recommendations, inspector + authoriser signatory blocks, recommended next inspection date.
The editor auto-saves when switching tabs and on the manual Save button. Progress mirror at the top shows blockers count + percentage.
On every tab where required fields are missing, a count badge appears next to the tab name. The Summary tab carries the full missing-field list with click-to-jump links.
The engineer can save and walk away mid-test, then comes back, opens the inspection, and picks up where they left off.
From the job page, Issue certificate mints the EICR cert from the structured payload. The IET-style branded PDF reads the same
submission.dataJSONB and renders it with the right tables and signature blocks.
Why bespoke and not generic forms?
The Form Builder is great for variable check-sheets. BS 7671 isn't variable: Schedule of Inspection items, circuit-detail columns, and the legally-required signatory blocks are all fixed by the regulation. A generic field-loop renders these as a vertical stack of inputs. A bespoke editor renders them as tables that look like the paper form, which is what the engineer is mentally translating from anyway.
Tradeoffs of the bespoke approach:
No tenant-level field customisation: you can't add a "warning labels fitted?" custom field via the Form Builder for these. (BS 7671 is the form. If your firm needs extra checks they go in the generic on-site form bound to the same job type, though one inspection per type is the usual pattern.)
One code path per cert type: EICR ships first. EIC and MEIWC editors are next; until they ship, picking those types opens a "coming next" placeholder and recommends binding a generic Form for now.
Storage shape is fixed: keys like
distribution_boards[].circuits[].zs_measuredare hardcoded, not user-defined. The certificate PDF blade reads those keys directly.
Required-to-complete gate
The job won't let you mark Complete until the regulatory minimum is captured:
Client name + reason + installation address + premises type + extent of installation
Earthing arrangement
At least one Distribution Board with a reference, and at least one Circuit on it with a number, description, and result
Inspector name
General condition + overall assessment (Satisfactory / Unsatisfactory)
Next inspection date
Soft hints (RCD IΔn > 30 mA on a socket circuit, insulation < 1 MΩ, polarity fault, Zs over permitted) appear inline as warning rows under the relevant circuit but don't block completion: they nudge the engineer toward the right code on the result column. The hard block is server-side; the editor mirrors it client-side for the inline progress meter.
Permissions
jobs.forms.view: see the inspection on a job, open the editor read-only.jobs.forms.edit: fill / save (the engineer's everyday permission).jobs.certificates.issue: mint the final EICR PDF once the inspection is done.
What about EIC and MEIWC?
EIC (new installs / additions / alterations) and MEIWC (minor works that don't add a circuit) share the same architecture but have different layouts:
EIC: different signatory block (designer / constructor / inspector + departures from BS 7671); "interval to next inspection" instead of a fixed date; no Satisfactory / Unsatisfactory rating (it's a new-install certificate, not a condition report).
MEIWC: single page, one circuit, one set of test results, one signature.
Both ship with the same JobType binding pattern; bespoke editors land in subsequent S248b iterations.