The Fabric of our Society

The Fabric of Our Society column invites industry leaders to provide experience-based opinions and discussions on various topics. Diverse perspectives are respected and most welcome, but do not necessarily reflect the opinions of IESNYC or the Board of Managers. Want to contribute? Email [email protected]

October 2026

AI Won't Fix Lighting's Data Problem. It Will Expose It.

Foad Shafighi
Lighting Department Lead, HGA

AI can already help us summarize a document, compare options, draft a schedule, or take a first pass at a submittal. Used well, it saves real time. But the industry keeps stepping around a limit that has nothing to do with how clever a model is.

An AI tool inherits the quality of whatever data it is given. Feed it scattered, inconsistent, unverifiable product information and it hands that straight back to you, but faster and with higher confidence. That quick answer is not always a correct one.

So this is not really an AI story. AI is only shining a hard light on a problem that lighting has lived with for years: product documentation.

Lighting products are genuinely complicated. A single luminaire can carry a cutsheet, IES and LDT files, a driver sheet, an installation guide, a compliance report, a Revit family, and more. The same facts (we hope) are scattered among them, in different formats, organized differently by every manufacturer. A wattage in one place, a delivered lumens figure in another, a dimming limit only in the driver sheet.

Experienced lighting professionals work through this every day. A good designer, a good rep, a manufacturer's technical team know where to look and what to question. But it is slow, it does not scale, and software cannot do it reliably unless the information is structured clearly enough to be read, compared, and checked.

That gap is what I have spent the past year on. I practice as a lighting designer, and I build software. Seeing from both sides, my honest view is that without a clean data layer to stand on, AI in lighting is mostly a fancy toy.

This is why I created ULC, the Universal Luminaire Cutsheet: an open, machine-readable format for luminaire data. It’s not meant to replace anything: not the PDF, the IES file, the rep, or a manufacturer's own systems. It is meant to sit next to them as a structured record that a machine can parse and a person can check, holding a product's core facts in one consistent shape.

The precedent: ANSI/IES LM-63

Lighting has solved a narrower version of this before. The IES file took one aspect of a luminaire, its photometric distribution, and gave it a single open shape that every calculation tool can read, across manufacturers. ULC puts the same ask to everything else on the cutsheet. Where the industry already shares a nomenclature, it builds on that instead of inventing its own.

The upside, if it works, is practical: less of the manual re-keying that breeds errors. Products compared on the same terms instead of across mismatched PDFs. Missing information that surfaces early, while it is still cheap to fix. And because the format belongs to no single company, a product's data is not locked inside one vendor's platform or one aggregator's interpretation.

Traceability is part of the point. When a tool reports a value, you should be able to follow it back to the document it came from instead of taking the tool's word for it. That matters most when AI is in the loop. AI should not become a faster way to hide uncertainty; it should become a faster way to expose it.

Cons

The reasons for caution are just as real.

The first is adoption. Manufacturers already maintain a great deal: internal databases, PIM systems, websites, sales sheets, rep portals, BIM content. Asking them to support one more format can feel like a burden, and that worry is fair. A large global brand and a small specialist do not have the same resources, so partial adoption has to be a feature, not a failure. ULC must let a manufacturer start with the essentials and then deepen the record over time. That is why ULC grades records by completeness, from a basic Core level up to Full. The aim is not to punish a thin record, but to make its completeness visible and give manufacturers a path to improve it.

The second is maintenance. Product data does not sit still: drivers change, photometry is revised, certifications lapse, options come and go. A structured file is worth something only if its accuracy stays tied to the current product. A standard is not just a schema. It is a process, with rules for versioning, source documents, revision tracking, and responsibility. Without that discipline, a structured record is just a stale PDF in a new guise, and a more dangerous one at that, because software will trust it.

The third is false precision. Specification still takes judgment. A shared structure can tell you what a product is, but it cannot tell you whether it belongs in your space. It cannot weigh glare, comfort, atmosphere, the quality of a detail, or how a fixture will actually read in the mock-up. That line is worth defending. Structured data and AI should remove the repetitive lookup work, not flatten design into a checkbox comparison.

Consensus

The fourth concern is the most formidable. It is not a technical problem at all.

A shared standard is only worth anything if it is genuinely shared, and that takes a real conversation across an industry that rarely sits at one table. Designers must say what information they actually need. Manufacturers must offer what is realistic to provide and maintain. Reps must share where information breaks down on real projects. The people building the tools must contribute structures that reliable automation requires.

Pulling those voices together and keeping them in genuine dialogue rather than parallel monologues, is far harder than writing any schema. ULC is my proposal for starting that conversation, not the end of it. A standard only matters if it survives real use: messy product data, incomplete documents, manufacturer constraints, rep workflows, and the pressure of active projects.

The PDF cutsheet is not going anywhere, and it should not. It carries intent, branding, and the visual logic of how a product goes together in ways a data file cannot. But on its own, it is no longer enough for the way we are beginning to work with AI.

The unglamorous truth is that lighting does not need more AI excitement. It needs product information that software can read, and people can verify. Get that right, and the tools will follow.

We can never automate taste. The point of ULC is to clear away the hours we lose chasing and re-checking numbers. Do this and the judgment that sets good lighting apart has more time to work.