Parametric Electrical Families
One host-family pattern per structural type, absorbing every SKU variation as data rather than geometry — documented as a 38-slide build guideline.
Key Techniques
Standalone Host
One family per category, with every SKU nested as a shared sub-family gated by its own Yes/No parameter.
5-Point Adaptive Host
Fixed-geometry placement for post caps and corner lights, with a 3-point variant derived from the same host.
Line-Based Host
Continuous arrays along a length parameter, driven by size_lookup() against an external table.
Search by Code
Four real-world code formats resolve through nested IFs to one design number that drives every variant.
Project Stats
- Role: BIM content design
- Categories: 9
- SKUs: ~60
- Yes/No formulas: ~90
- Deliverable: 38-slide guideline
Project Overview
Pergola lighting specs ship as dozens of near-identical SKUs — same category, different voltage, wattage or physical variant. Modeling each SKU as its own Revit family multiplies file count and breaks schedule consistency the moment a spec changes.
The brief was to design one host-family pattern per structural type that could absorb all SKU variation as data, not geometry — so a BIM user picks a product code once and the correct fixture, wattage and visibility resolve automatically.
Three architectural patterns
| Section | Family type | Placement logic | Categories |
|---|---|---|---|
| A | Standalone host per category | One family, N nested SKUs switched by Yes/No | 9 |
| B | 5-point adaptive host | Fixed-geometry placement | 4 |
| C | Line-based host | Continuous arrays along a length | 9 |
Process
1. Reverse-engineering the existing pattern
Before documenting anything, I audited the existing families to extract the implicit rules already in use — naming conventions, parameter groupings, formula shapes — so the guideline codified real practice rather than an idealised process nobody would follow.
2. Section A — the baseline pattern
A host family nests every SKU as a shared sub-family, each gated by its own Yes/No visibility parameter. The naming convention encodes category, product code, voltage and wattage, so the parameter list is self-documenting without a lookup table.
IG_914_220V_2W
3. Section B — adaptive placement
A 5-point adaptive family acts as the host, with a 3-point variant derived from it — built not as a separate family but as the 5-point host with the last two points deleted and re-saved. A Search by Code input accepts four real-world formats and resolves them to one design number:
ARC1000932 · ARC-1000932 · 1000932 · 932
4. Section C — continuous arrays
Line-based families needed a different strategy entirely. Rather than nested IF chains per category, I used Revit’s size_lookup() against an external table — decoupling formula from data so the table can be extended without editing the family.
5. Auditing the edge cases
Hardscape Light — one SKU only
No per-variant chain is needed; the category-level Yes/No is the switch. Documented side by side against the multi-variant pattern so the simplification reads as a deliberate choice, not a gap.
Bollard / Focus — context-dependent wattage
The same product code carries a different wattage between Sections B and C. Called out explicitly rather than silently reconciled, since both reflect real supplier data.
6. Formula reference architecture
With roughly 90 formulas across three sections, a single dense table became illegible. I split the reference into one page per category, each sized to its own variant count — two formulas get a spacious single column, nineteen get a compact two-column grid — rather than forcing one density across every category.
Outcome
A 38-slide reference where every formula is copy-pasteable straight into Revit’s parameter editor, organised so a modeler can find “how do I wire Bollard Lights” in under ten seconds — without reading the fourteen-step derivation that produced it. The three architectures became the R&D foundation that developers built automation plugins on top of.