-
The claim I'll defend
-
Argument 1: Product cycles have outrun project cycles
-
Argument 2: Controls are a line item now, not a footnote
-
Argument 3: The emergency is upstream of the emergency
-
The objection I always get: "value engineering is just how it works"
-
Honest limits
-
What I'd put in the spec now
-
So here's the restatement
The claim I'll defend
Most of the "emergency" lighting orders moving through distribution right now aren't emergencies. They're spec debt — the accumulated cost of specifications written for a lighting industry that has since moved on.
I coordinate rush and expedited orders for a commercial lighting supplier. Which means I'm the person who gets the 9:40 a.m. Thursday call when a project in Denver suddenly needs 240 recessed downlights in five business days, or when a hotel opening in three weeks discovers the lobby fixtures ordered in March won't dim on the control system installed in June.
I've handled 200+ rush jobs over four years. The shape of those orders has changed.
In 2021 — well, in 2021 and most of 2022, honestly — rush orders were logistics problems. A container rolled. A truck was late. A client doubled a quantity. Real emergencies.
In 2025, the majority of what I triaged was different. Not logistics. Specification. Three out of five rush jobs last quarter traced back to something that was already wrong on the spec sheet long before anyone called me — a discontinued SKU with no approved substitution, a control protocol mismatch, a lumen maintenance assumption that didn't survive contact with published LM-80 data.
That's the pattern I want to argue about.
Argument 1: Product cycles have outrun project cycles
Here's the arithmetic nobody puts in the submittal. A mid-size commercial project — hospitality, education, light industrial — typically spends 18 to 36 months between design development and fixture installation. Over that same window, the commercial LED market refreshes roughly every 24 to 36 months on the fixture side, and considerably faster on the controls side.
What I mean is that a specification signed in the spring of 2023 is, by the time it's installed in 2026, describing a market that no longer exists in the shape it was written — not because the spec was bad, but because the shelf it was written against has been restocked twice, and in some cases the SKU has been retired entirely.
LM-80 test data and TM-21 projections are the standards here (both from IES). They're published per product, not per family. When a fixture is discontinued, the LM-80 file doesn't transfer — the replacement needs its own published data. If the spec says "or equal" without a defined equivalence test, the substitution becomes a judgment call made in the field by whoever is holding the RFI that afternoon.
That's where my phone rings.
Argument 2: Controls are a line item now, not a footnote
For most of the last two decades, "controls" in a commercial lighting spec meant a dimming protocol, a sensor schedule, and a note that said "by others." That was a 2010s structure.
The 2026 structure looks different. Controls now determine whether the fixture is usable in the space at all. A recessed downlight that hits every photometric target in the submittal can still be the wrong downlight if it can't speak the protocol the building's system uses.
Three protocols show up constantly, and they don't automatically talk to each other: 0-10V (analog, cheap, limited), DALI-2 / D4i (digital, addressable, increasingly the commercial default), and Zigbee (mesh, used widely in smart-home and light-commercial ecosystems).
Concrete example, because I've lived it. A mixed-use project — ground-floor retail, residential above — came to me after the fact. The design team had specified Philips Hue recessed downlights for the residential amenity spaces and a DALI-2 system for the commercial core. Both choices were defensible on their own. Philips Hue is Zigbee-based and does exactly what it was built to do: plug-and-play control, straightforward app-level management, zero commissioning contractor required. DALI-2 is the right backbone for a building-scale system with centralized monitoring and fault reporting.
They just don't merge. You don't get a single pane of glass. And if the spec doesn't say that out loud, someone downstream will assume you do.
(Should mention: this isn't a product problem. It's a specification problem. Both ecosystems do what they were designed to do.)
Same story with Philips floor lamps in a hospitality lobby. Hue floor lamps are a clean answer for a lounge that needs scheduled scene changes with zero infrastructure. But if the architect buried them in a spec section under "decorative luminaires — see electrical," the lighting designer never saw them, the controls designer never integrated them, and the hotel opens with a floor lamp that works beautifully in a lobby that doesn't match the render.
Argument 3: The emergency is upstream of the emergency
Last quarter I logged just under 50 rush orders. I went back and tagged them by root cause. The breakdown was uncomfortable.
About 30% — or rather, closer to 28%, but the rounding doesn't change the point — were genuine logistics failures. Freight, customs, warehouse errors. Those are real emergencies and there's not much a spec can do about them.
The remaining 70% broke down roughly like this: discontinued fixture with no approved substitution (largest single bucket), control protocol mismatch discovered at commissioning, photometric shortfall discovered on site, and certification gaps — usually a DLC listing question or a Title 24 compliance issue on a fixture that was never actually on the qualified products list to begin with.
None of those were emergencies on the day the phone rang. They were latent defects in a document that had already been approved, sealed, and issued for construction. The emergency was just the moment the defect became visible.
Speed doesn't fix them. You can't expedite a compliance problem. You can't pay a premium to make a Zigbee fixture speak DALI. The best I can do on those calls is find the least-bad workaround and hope the AHJ agrees with it.
The objection I always get: "value engineering is just how it works"
Fair. I hear it every time. And I'm not arguing against value engineering.
The problem is when it happens. Value engineering done on the spec sheet, before the bid, with the lighting designer in the room and the manufacturer's published data open — that's a discipline. It saves money and nobody notices it happened.
Value engineering done after the GC has fixtures on site, by whoever is holding the substitution request at 4 p.m. on a Friday — that's a rush order waiting to happen. And the money it "saves" is usually eaten within two weeks by expedite fees, re-shipping, and the labor cost of re-installing the wrong thing.
Looking back at one specific job, I should have pushed harder to get the substitution approved two months earlier, when there was still schedule room to do it properly. At the time the timeline looked comfortable and everyone assumed the original fixture would ship. It didn't. We paid a substantial rush premium to land an approved equal, and the client still lost four days on the ceiling grid. If I could redo that call, I'd have escalated on day one of the first slip, not day thirty.
Honest limits
I'm not sure why some spec sections still get approved without a controls compatibility note, and I've stopped guessing. My best hypothesis is that the fixture schedule is written by one party, the controls narrative is written by another, and the two documents never get reconciled before issuance. If someone has actual data — a study of RFI causes at commissioning, for instance — I'd genuinely like to see it.
What I'd put in the spec now
Three things, in this order.
First, a controls column. Every fixture row in the schedule gets a protocol, a named commissioning owner, and a stated integration target. "Dimmable" is not a protocol.
Second, a substitution protocol with a defined test. Not "or equal." Rather: substitution must match or exceed published LM-79 photometrics, carry current LM-80 data with a TM-21 projection, and be listed on the DLC QPL at the specified CCT and CRI. That's a sentence a recessed lighting distributor can actually act on without a conference call.
Third — and this is the one that quietly saves projects — a fixture lifecycle statement. Ask the manufacturer's rep, in writing, for the published availability window of the specified SKU. If it's already in its final production year, plan the substitution now, not eighteen months from now.
Compliance references worth pinning to the spec book: the DLC Qualified Products List for rebate eligibility; California's Title 24 Building Energy Efficiency Standards — the 2025 edition applies to permit applications filed on or after January 1, 2026, so verify current applicability at the California Energy Commission before assuming the previous version governs. On the controls side, Zhaga Book 18 and the D4i certification program define what "interoperable" actually means on a data sheet, and Matter is worth tracking as the consumer-side convergence layer over Zigbee-based systems.
Rates and listings change. Verify at the source, not from a spec that's two years old.
So here's the restatement
The lighting industry didn't get worse. It got faster, and it got more interconnected, and the way we document it didn't keep up.
What was best practice in 2019 — a fixture schedule with model numbers and a "by others" note on controls — carries real risk in 2026. Not because the old approach was lazy, but because the market it described has been restocked twice since.
There's no shortage of spotlight specification guides online. Almost none of them ask the one question that matters: who owns the commissioning signature when the fixture is installed, the controls are live, and the two don't agree?
The emergency calls I get will keep coming. Some of them will always be freight and weather and human error. That's the business.
But 70% of them don't have to exist. They exist because a document got frozen at the wrong moment, and nobody reopened it.
Reopen the spec. It's cheaper than calling me.