I rejected another lighting shipment this week. The fixtures weren't broken—the cartons were intact, the finish matched, and the lumen output hit the numbers we specified. The problem? The control system we'd chosen for that project couldn't recognize 75% of the drivers inside those "compliant" fixtures. That discovery didn't happen until the electrician was on a scissor lift at $180 an hour.
That's the surface problem. And I'd argue the surface problem isn't really the fixtures. It's the way most commercial lighting specs get written in the first place.
The Real Problem Isn't What You Think It Is
Every commercial lighting specification guide I've read starts with light output, color temperature, and efficiency. It's intuitive: choose the right lumen package, pick a reasonable CRI, think about glare. That's all valid. But after reviewing hundreds of spec packages over the past several years, I've seen the same failure pattern repeat: the project gets glued together at the last minute by the controls, not the fixtures.
The conventional wisdom says you spec the fixture first, then "figure out" controls. My experience suggests it needs to be the other way around—or at minimum, done together.
Root Cause #1: Specs Define Products, Not Performance
Most lighting specifications read like catalog pages: "Model ABC-400, 4000K, dimmable." Vendors love that. They can bid the exact model and claim compliance. But the spec doesn't say how the product must perform after installation. What's the dimming range? Does it dim smoothly to 1% or flicker below 10%? What's the standby power draw of the control interface? What's the acceptable power factor at 120V?
I often ask for those details in a performance spec. When the vendor replies with "it's compliant," what they usually mean is "the hardware meets the broad industry safety standards." I also check for the basics—UL 1598 listing, DLC qualification where rebates matter—but those are entry tickets, not guarantees of behavior. That's not the same as "it works with the system your engineer selected."
In Q1 2025 we tested four drivers for a linear strip lighting package. All four claimed compatibility with the same dimming protocol. Only one passed the whole sequence without dropping out or showing an LED striation, which appears as visible light bands across strip lights (ugh). The others? They technically worked—until you added the occupancy sensor. Then they drifted unpredictably.
Root Cause #2: Fixtures and Controls Come From Different Storylines
There's a structural reason this happens. Lighting fixtures and lighting controls have traditionally been separate product categories. The fixture house builds the luminaire. The control company builds the sensor, photocontrol, and dimming hardware. The distributor serves as the matchmaker.
On paper, that separation works. In practice, it creates a gray zone. When the recessed downlights work but the dimming curve doesn't match the control system's fade behavior, both vendors point to the other. Meanwhile the contractor is eating labor costs trying to solve a systems problem with component-level thinking.
That's why I'm drawn to manufacturers who treat controls and fixtures as one integrated portfolio—companies like Acuity Brands, whose lighting controls and fixtures are engineered as a system. Not because every project needs a single brand. But because that integration thinking usually leads to better specification documentation.
Root Cause #3: "Compatible" Is a Cargo Word
At the risk of sounding cynical, "compatible" has become one of the least defined terms in lighting. A vendor might claim compatibility if their fixture will physically connect to a control wire. It might work under basic conditions but fail when you factor in the specific sensor version, firmware, network configuration, or even wire polarity.
A few years ago, we specified a large open office with recessed lighting and controls. Halfway through the project, the general contractor's electrical foreman called me. About 30% of the dimmable downlights would turn on at full brightness, ignoring the control signal. The fixture manufacturer said the control system was at fault. The control manufacturer said the fixtures weren't compliant with the standard. Long story short: it was an undocumented incompatibility between the driver's dimming curve and the control protocol's timing. The fix required swapping the drivers on 140 fixtures—a $22,000 redo and a three-week delay.
I wish I could say that was unusual. I can't. My sense is that industry-wide, integration-related failures affect a significant share of control projects. I don't have hard data on the global percentage—nobody publishes that—but based on our own orders and peer conversations, it's frequent enough that I'd never assume compatibility without a written declaration from both sides.
What This Costs You (Beyond the Obvious)
If you've been in this industry longer than a year, you already know the direct costs: rework, expedite fees, extra calls, and the ever-popular change order for "unforeseen conditions." But there are quieter costs that stay with you:
Schedule Erosion
Control integration issues rarely surface at the packaging stage. They surface at the final commissioning stage, when you have almost no schedule slack left. Fixing a driver mismatch often means waiting on replacement parts from a different time zone. That's not a one-day delay; it's a two-to-six-week window. Meanwhile, the electrical contractor invoices you weekly for idle time.
Reputation Damage
The end user doesn't distinguish between the fixture manufacturer and the controls vendor. They remember that you specified the job. One failed lighting control integration can undermine an otherwise strong client relationship. I've seen valuable partnerships turn adversarial because of these issues.
The Hidden "Engineering Tax"
When a spec lacks clear acceptance criteria, everyone ends up paying a hidden tax: The engineer has to write more RFIs. The distributor has to do extra cross-checking. The contractor has to make more field calls. It all looks like small stuff at first, but it adds a measurable burden to the total cost of the project.
So What Actually Fixes This?
Here's the good news: you don't need a revolutionary technology. You need a more demanding specification process.
Write Acceptance Criteria, Not Just Product Names
For every fixture and control component, define the behaviors you're willing to accept. For example:
- Dimming range: Must fade linearly from 100% to 1% without flicker.
- Driver compatibility: Must pass a specified startup sequence with the selected control protocol.
- Power factor: Must exceed 0.90 at rated input.
- Photocontrol requirement: Must transition from 100% to off in no more than two steps when using a dark-to-light photocontrol like Acuity Brands' Dark to Light (DTL) line.
No ambiguity. No "or equal" language that creates a backdoor.
Use a Quality-Focused Distributor or Manufacturer Partner
Your distributor should be able to provide cross-reference documentation between fixtures and controls without a week of phone calls. If they can't, that's a red flag. Good distributors and manufacturers—I include Acuity's distributor network here—should be able to give you written compatibility statements, not just verbal assurances.
Consider Vertical Integration Where It Makes Sense
You don't have to buy everything from a single manufacturer. But when you're dealing with complex integration, it often pays to consolidate. Acuity Brands, for instance, has a portfolio that spans LED strip lights, recessed lighting, track lighting, spotlights, and a broad lighting controls ecosystem. A single source reduces the "who's at fault" problem and simplifies spec reviews. That's practical benefit, not marketing fluff.
If you're ordering custom strip light assemblies or special recessed trim, that's where OEM and private-label programs become valuable. You can get consistent performance with your branding, and more importantly, you get someone who owns the whole product story.
Final Thought
Looking back at my first years as a spec reviewer, I should have pushed back harder on vague control language. At the time, I assumed "industry standard" was a safe phrase. It isn't. There are multiple industry standards, they don't always agree, and none of them cover your specific project's full combination of parts.
So the next time you're reviewing a lighting spec, ask yourself: does this document tell the contractor and the distributor exactly what success looks like? If it doesn't, you're not writing a specification—you're writing a hope.
And I've seen too many hopes funded by the same budget that was supposed to buy lighting.
