To run a useful lighting plan review, label each comment by the question it leaves open. That question is about the layout, the product documentation, or a site condition. Make that call before anyone redraws a sheet or swaps a fixture, because a fixture change only answers one kind of problem.
A comment that says "use a different fixture here" might really be about spacing on the drawing, a missing detail in a submittal, or a ceiling that doesn't match the plan. Sort it first. Then pick the check that fits, and revise only after that check shows what needs to change.
Sort Each Comment Before Choosing a Revision
Classify a comment by the unresolved question it raises, not by the fix it suggests. The suggested fix is useful context, but it is the reviewer's guess at an answer.
Start every entry the same way. Copy the comment word for word, or keep its full meaning if you must shorten it. Add the sheet number, view, room, or site location it points to. Then write two short lines: what the reviewer says is wrong, and what change they are asking for. Those two lines often point to different categories, and that difference is what keeps a team from revising the wrong document.
Use this table as a triage aid to choose the first check. It does not replace review by the people responsible for the design.
| Issue type | Comment signal | Next check |
|---|---|---|
| Layout | Points to arrangement or placement shown on a sheet | Inspect the referenced plan area |
| Product documentation | Names product information or cites a project requirement | Compare the cited documents with that requirement |
| Site condition | Describes a physical condition at the project | Verify the condition at its location |
A category label is a starting point, not a verdict. If a comment fits more than one row, or the condition it describes hasn't been confirmed, keep it open and handle it with the split method later in this guide.
Review Layout Comments Against the Plan
A layout comment calls for a closer look at the drawing before anything else changes. The goal is to state the exact plan question so the right person can answer it.
- Open the cited view. Go to the sheet, view, room, or marked area named in the comment. Note the drawing reference and the specific arrangement or interface the reviewer flagged, such as fixture rows near a wall or lights shown across a ceiling change.
- Confirm it is really a layout issue. Ask whether the concern is the arrangement as drawn. If the comment actually questions a product's data or a field condition, move it to that category instead.
- Write the open question precisely. "Is the row spacing in the east aisle what the owner intended?" is something a designer can answer. "Fix lighting in east aisle" is not.
- Hold off on fixture swaps. Swapping a fixture doesn't answer a question about where lights sit on the plan.
Some layout questions can't be settled from the drawing alone. When the open item is whether the arrangement serves the task area, it becomes a design question. Our guide on requesting a photometric layout explains when that kind of study helps. Route the question to the reviewer your project documents name as responsible for the design.
Check Product Documentation Against the Comment
A product documentation comment needs a document-to-requirement comparison. Do that before anyone treats substitution as the answer.
- Product identity. Record the product identifier exactly as it appears in the project file, not as someone remembers it.
- Cited document. Note the submittal, cut sheet, or data file the comment refers to, including its title and revision.
- Project requirement. Name the specification section, schedule line, or other requirement the reviewer cited.
- Exact gap. State what is missing or inconsistent, such as a value that differs between two documents or a required item that isn't in the submittal.
This comparison tells you what kind of problem you have. A missing page or an outdated revision is a documentation problem, and the fix is a clarification or a corrected document. A confirmed mismatch between the product and the requirement is a different finding, and it needs a different decision. Don't infer a mismatch from a product name alone.
When a comment involves photometric data files, our checklist for matching IES files to fixtures shows how to line up the file with the product it describes. Questions about compatibility, performance, certification, or code fit go to the reviewer your project documents name for that judgment.
Verify Site-Condition Comments at Their Location
Treat a site-condition comment as a report until someone confirms it at the place it describes. Only a confirmed condition should justify a layout or product change.
- Locate it. Tie the comment to a specific room, grid line, bay, or other area that someone else can find.
- Verify what is there. Check the condition in person or through the person assigned to the site. Record the field note and, if project procedures allow, a labeled photo.
- Compare with the plan. Set the verified observation next to the plan information it affects. A beam, duct, or ceiling height that differs from the drawing becomes a real input only after it is checked.
- Record what is still uncertain. Mark any part that couldn't be confirmed, and leave any design judgment open.
A photo or field note documents what someone saw. It does not settle whether a design is adequate or compliant. If you can't verify the condition yourself, assign a site check through the project's documented process rather than assuming a fixture change will cover it. To capture clean evidence the first time, collect site measurements and photos using a consistent labeling method.
Split Overlapping Comments and Route Open Questions
When one comment mixes categories, split it into linked entries so each question gets its own check. Some open items also need a decision outside your role, and those follow documented project channels.
- Keep the original. Save the full comment and its drawing or location reference as the parent entry, so every follow-up keeps its context.
- Separate the parts. Write the observed condition, the requested change, and the unresolved question on separate lines. The proposed fix is not the finding.
- Create linked entries. Give each distinct layout, product documentation, or site question its own entry under the shared comment reference. Each one gets its own category and next check.
- Name the open decision and its route. For each entry, state the question and the response needed. Use project documents, such as the contract, responsibility matrix, or submittal procedure, to find who reviews it.
Here is an illustrative example. A field note says "fixtures won't fit above the duct in Room 12; use surface mount instead." That one line holds a site condition (the duct position), a layout question (whether the plan accounts for the duct), and a product change (a new mounting type). Each part becomes its own linked entry. If the mounting change goes forward, review mounting substitutions before approval.
Never close a comment that needs electrical design or a code or permit interpretation as a routine fixture revision. Send that judgment to the qualified reviewer your project names and to the authority for the project's state and local jurisdiction. Review paths vary by location, so confirm the jurisdiction first instead of assuming one US process.
FAQs
Who should answer a code or permit comment?
Start with the project documents. They may name a designer, engineer, or other party responsible for code questions. Then confirm which state and local jurisdiction governs the project, since that sets which authority reviews permits and code interpretations. Review processes differ across US jurisdictions, so don't assume a contractor, supplier, or owner rep has approval authority unless the documents say so.
What if reviewers disagree about the same comment?
Keep both positions in the log with their names, dates, and references. Don't merge them into one line or delete the one you think is wrong. Then figure out where the disagreement sits: do they disagree about what exists, or about how to resolve it? A disagreement about what exists usually calls for verification. A disagreement about the fix goes through the project's documented coordination path.
When can a plan comment be marked resolved?
A comment stays open while its underlying question is unnamed or the required response hasn't arrived. Close it once the person with the documented role has answered. Record the outcome, such as accepted, revised, or no change needed, and link any revised sheet or corrected document by its revision. If the project has its own closeout steps for comments, follow them so the record holds up later.
