Start with a fixture-by-fixture evidence register, not a folder of unrelated cut sheets. Give every proposed fixture family or materially different configuration its own record. Identify the item, link to its supporting files, and separate verified information from assumptions, clarification requests, substitutions, and open questions. This makes the commercial lighting submittal easier to compare, but it does not establish approval or acceptance.
Create a Fixture-by-Fixture Evidence Register for a Commercial Lighting Submittal
Build the register around the reviewer's task: identify the proposed fixture, compare it with the project requirements, and locate the evidence without searching through unrelated attachments. Use the fixture schedule or index as the first package artifact; the cited guidance presents that schedule as an abbreviated product index supported by more detailed documentation. See the lighting fixture schedule guidance for this traceability principle.
Create one record for each fixture family, series, or materially different configuration. A single-fixture package may need only one record; a multi-fixture package should repeat the same fields without blending variants. Include the fixture tag, exact model, selected options, source filename, revision or date when available, status, and affected project requirement. Use statuses such as supplied or verified, clarification needed, substitution item, or not applicable only when the project documents support that classification.
Use this 10-category register as a practical framework. Reconcile it with the contract documents, drawings, controls information, owner standards, and responsible reviewer's instructions rather than treating it as a universal commercial lighting submittal checklist.
- Fixture identity: Record the fixture tag, manufacturer, exact model, series, housing or form factor, and selected options. The reviewer should be able to tell precisely what is being proposed.
- Photometric file: Attach the applicable IES file or other project-required photometric evidence and record its filename and revision. Identify the configuration it represents.
- Electrical data: Capture the applicable voltage, wattage or selected setting, current or driver information, CCT, lumen information, dimming interface, and emergency configuration. Mark missing or conflicting values instead of choosing the most favorable one.
- Mounting and dimensions: Include dimensions, mounting type, suspension, brackets, hardware, cutout or attachment details, and installation drawings when applicable. Put retrofit assumptions in a separate field.
- Controls: Identify the required control method, sensors, dimming interface, control zones, or sequence information that applies to the fixture. Fixture literature alone may not describe the project's complete controls sequence.
- Accessories: List reflectors, lenses, guards, photocells, sensors, brackets, wiring components, and other selected accessories. Link each accessory to the fixture configuration and installation interface.
- Environmental documentation: Add project-required records, such as maintenance or compatibility documentation, when the governing documents call for them. The project documents determine which records belong here.
- Assumptions: State conditions that are not confirmed, such as existing dimensions, wiring, mounting, controls interfaces, or retrofit conditions. Keep these statements outside verified fixture data.
- Substitutions: Identify whether the item differs from the basis of design or specified product. Do not bury the difference in a general product description.
- Open questions: Write each unresolved issue as a specific question, identify the affected fixture and responsible party when known, and name the document or decision that would resolve it.
The result is commercial lighting documentation that lets a reviewer see both the proposed fixture and the limits of the evidence. It supports comparison and clarification, not a claim of code compliance, project approval, bid acceptance, or product suitability.
Package the Files for Like-for-Like Comparison
Arrange the package so the reviewer sees the index, followed by one complete, repeatable evidence record for each fixture. Keep project-wide documents in a separate, labeled group and cross-reference the fixture tags they affect. This sequence exposes missing files without forcing the reviewer to infer which attachment belongs to which configuration.
Build a Predictable Package Sequence
Place the fixture index or schedule first. Follow it with the fixture records in a fixed order: identity, photometric, electrical, installation and mounting, controls, accessories, environmental records, assumptions, and exceptions. Use the same order for every fixture record, even when the package contains only one proposed item.
Keep unlike series, variants, selectable settings, and configuration-specific files separate. If two records use the same family but different wattage, CCT, voltage, optics, mounting, controls, or accessory selections, give each proposed configuration its own evidence trail. Do not include empty option sections that imply an unsupported feature.
Controls, mounting, accessories, wiring diagrams, and compatibility records may be required in addition to product data when the project specification calls for them. A public lighting specification illustrates these separate evidence categories and the need to confirm fixture compatibility with the proposed installation. Use that lighting evidence example as a workflow reference, not as a nationwide minimum.
Name Files for Traceability
Use a filename that answers four questions: which fixture, which model or configuration, what document type, and which revision or date? For example, a project might use a pattern such as A-101_Model-XYZ_IES_Rev2.pdf, provided it matches the project's file-management rules. This pattern is a practical convention, not a mandatory industry standard.
Point from the index to the exact attachment and preserve the same identifier inside the record. Keep revised files clearly distinguished from superseded files, and do not let a generic family cut sheet stand in for a configuration-specific document. Product listings can help locate current model information, but they do not replace the evidence required by the project documents.
If the package includes IES files, match each file to its fixture and configuration before sending it. Use the filename and record identifier to make that relationship visible.
Verify That Each Evidence Set Matches the Requirement
Before sending the package, compare each exact fixture configuration with the fixture schedule, specification, drawings, controls intent, and other applicable project documents. Mark the record verified from supplied evidence, clarification needed, or substitution item. If the requirement or data field is unclear, ask a specific question rather than infer compliance from a related product family.
Match Photometric and Electrical Evidence
A cut sheet identifies and describes a product. An IES file is a standardized digital representation of a luminaire's light-distribution characteristics used by calculation or simulation software, so it serves a different review purpose. The IES file definition also identifies manufacturer and model information within the file. Confirm that the IES file, product literature, electrical data, and selected configuration describe the same manufacturer, model, and proposed options.
Compare the submitted information with the applicable requirements for voltage, wattage or selected setting, CCT, lumen information, dimming or controls interface, and emergency configuration. Do not promote a generic value when the selected configuration is different. If a file is missing, a value conflicts, or the file identifies only a broader family, mark the record for clarification.
| Document | What it supports in review |
|---|---|
| Product cut sheet or data sheet | Product identity, construction, options, dimensions, ratings, and other listed details |
| IES photometric file | Standardized light-distribution data for the identified luminaire and the project's calculation or simulation workflow |
Neither document alone establishes approval. The reviewer still needs the proposed configuration and the project requirement that the evidence is intended to satisfy.
Match Installation and Project Requirements
Check mounting, dimensions, suspension or brackets, controls, accessories, and environmental documents against both the fixture record and the project conditions. A fixture-only document does not prove a complete controls sequence or installation interface. For a retrofit, separate confirmed existing conditions from assumptions about wiring, mounting, ceiling or wall dimensions, and controls.
Use a project-specific submittal review checklist tied to the final specification documents, and add notes for the actual package. The checklist helps organize the comparison; it does not turn an incomplete requirement into a verified result. If any project-required document is missing or the governing package is inconsistent, ask the responsible reviewer for clarification.
Route Exceptions Before You Send the Submittal
Use a simple final rule: send when fixture identity, required evidence, cross-references, and revisions are traceable; clarify when a known requirement, value, file, option, or interface is missing or conflicting; escalate as a substitution when the proposed fixture differs from the basis of design or may affect documented installation or coordination requirements. Sending the package is a routing action, not approval.
Make Assumptions and Open Questions Visible
Attach every unresolved item to the affected fixture record. Useful fields include the fixture tag, question or assumption, known impact, responsible party, requested response, and resolving document or decision path when known. For example, do not write "retrofit details pending." Ask whether the existing mounting and wiring support the proposed configuration, identify the affected tag, and state which site information or project decision is needed.
Keep assumptions outside verified data. A missing control interface, uncertain emergency requirement, incomplete existing-condition measurement, or unavailable environmental record should remain visible until the responsible party supplies or resolves it. This gives the reviewer a precise clarification request instead of a package that appears complete only because uncertainty is hidden.
Document and Route Substitutions
Create a side-by-side substitution record with the basis-of-design reference, proposed fixture and exact configuration, applicable evidence, documented differences, coordination impacts, and requested review route. Compare physical description and dimensions, photometric data, electrical data, accessories, warranty information when the project requires it, and other project-specific qualities. Official substitution documentation guidance supports making significant differences and coordination effects explicit, while the public lighting specification provides a side-by-side lighting comparison example.
| Comparison field | Basis of design | Proposed difference or impact |
|---|---|---|
| Physical and mounting | Specified description, dimensions, and installation method | Proposed dimensions, mounting, and site coordination |
| Photometric and electrical | Required data and specified configuration | Proposed file, settings, electrical data, and documented variance |
| Controls, accessories, and warranty when required | Required interfaces and project conditions | Proposed components, compatibility questions, warranty evidence when required, and documented impact |
Keep a substitution separate from a clarification. A clarification resolves uncertainty about the requirement or proposed configuration; a substitution presents an alternative against the specified basis of design. In either case, follow the project's procedures and do not describe a listed, transmitted, or documented substitution as accepted before the responsible reviewer acts.
Complete the register from the governing project documents, then route each missing evidence item or product-specific question to the appropriate project contact or responsible reviewer. The finished commercial lighting submittal should make review straightforward by showing what is documented, what is assumed, and what still needs a decision.
Frequently Asked Questions
The questions below address common documentation decisions that can affect whether a reviewer can trace the proposed fixture and its supporting evidence.
What documents belong in a commercial lighting submittal?
Start with fixture identity and configuration, then gather applicable photometric and electrical evidence, installation and mounting details, controls and accessories, project-required records, and a visible list of exceptions. Reconcile those groups with the project specification and reviewer instructions before sending the package.
What is the difference between a cut sheet and a photometric file?
A cut sheet describes the product and its listed features. An IES file contains standardized light-distribution data for calculation or simulation. Match the file to the submitted model and configuration, and treat neither document as proof of approval.
How should a contractor document a lighting substitution?
Name the basis-of-design item and the proposed fixture and configuration. Compare documented physical, photometric, electrical, accessory, warranty, and coordination differences when applicable, attach the supporting evidence, and route the request through the project's substitution process. Inclusion in the package is not acceptance.
What should a contractor verify before sending a lighting submittal?
Confirm identity-to-file matching, required electrical and mounting information, controls and accessory interfaces, revision consistency, and visible unresolved questions. Then send a traceable package, request clarification for known gaps, or route a substitution when the proposal differs from the basis of design.
