Solar Design Review Checklist: A Release Method for Installer Teams

A solar design review is useful only when it tests a design against the decision it will support. A concept for a first customer discussion, a permit submission, a procurement instruction, and an issued-for-construction package have different thresholds. The review should say what the package is ready for, what it is not ready for, and what evidence supports that conclusion.

This desk-research guide is for installers and EPCs building a repeatable design-release practice. It does not prescribe local code or replace qualified engineering, field verification, manufacturer instructions, utility interconnection requirements, or authority approval. Use the applicable rules and project documents as the controlling source.

Set the Review Level Before Opening the Drawing

“Approved” is an unhelpful status unless it has a context. A designer may approve an early option for a sales conversation while an engineer has not reviewed an electrical condition. A project manager may accept a package for procurement only after equipment availability is confirmed. Put the review level at the top of the record.

The table is not a universal approval matrix. Different markets and project types require different reviewers. Its value is that it prevents a concept drawing from gaining authority simply because it looks polished. The release label should travel with the PDF, model, drawing set, and project record.

Begin With the Design Basis

A reviewer should not start by counting panels. Start with the evidence that made the layout plausible. The design basis is a concise account of site identity, use case, consumption or load information where relevant, roof or land constraints, equipment assumptions, and the intended output. It is the map for finding mismatches later.

Ask these questions:

1. Is the property or facility correctly identified, including the relevant roof, parcel, or electrical-service context?
2. What source established geometry, obstructions, tilt, access limitations, and other physical constraints?
3. Which inputs were measured or surveyed, and which are provisional remote estimates?
4. What customer objective is the design meant to examine: energy cost, on-site consumption, backup, development planning, or another purpose?
5. Are significant tariffs, load assumptions, operational schedules, or financing inputs dated and sourced?

The National Renewable Energy Laboratory photovoltaic research program offers technical research context for PV systems. It does not establish a project’s site conditions or prove that a proposed layout is compliant. The actual review needs current project evidence and the controlling requirements in the project location.

Check the Layout as a Set of Constraints

The panel layout is the visible center of a proposal, but review should be more than visual. Compare the array boundaries with the source information and with any stated setbacks, access routes, roof features, or construction constraints. If the model uses remote imagery, name its capture date and its limitations. If a field survey changes the geometry, the review should identify which downstream outputs must be updated.

A practical layout review asks:

• Are roof planes, orientation, obstructions, and array boundaries traceable to a source?
• Have walkways, access, fire, structural, drainage, roof warranty, or local requirements been referred to the applicable reviewer rather than assumed?
• Does the design show excluded areas clearly enough that another person will not interpret them as usable space?
• If the system includes storage or other equipment, is the space and routing concept described at an appropriate level for the release stage?
• Are proposed changes since the previous revision explained rather than buried in a new drawing?

This is a constraint check, not an assurance that every physical issue has been solved. A reviewer who finds a question should preserve it as an exception. The exception should say what evidence is missing, who needs to respond, and whether the package can still be used for its stated purpose.

Review Shading and Production Assumptions Separately

It is easy to blend a shading visualization with an energy conclusion. Keep them distinct. Shading analysis describes a model of obstructions and sun paths using defined assumptions; the production scenario combines that treatment with irradiance data, system configuration, losses, and other inputs. A well-presented report should not conceal that difference.

For every yield-related output, document the data source, model version, scenario, and material limitation. Check whether a new obstruction, changed array boundary, altered module count, or different orientation requires a refreshed analysis. A customer-facing annual value should be tied to the same configuration the reviewer sees in the design record.

Shadow Analysis is SurgePV’s product area for hourly shade and irradiance modeling. It can support a disciplined workflow, but it does not make remote information equivalent to a site inspection or replace the review required by the project’s local conditions.

Treat Electrical Review as a Compatibility Question

Electrical configuration requires information that is often absent from an early sales brief. A review should identify what is known about the modules, inverter, strings, service, protection, conductors, equipment locations, monitoring, and applicable requirements. It should also say which parts require a qualified person or later site confirmation.

Rather than asking “does the design look electrically correct?”, use narrower questions:

Do not convert this table into a code checklist for every jurisdiction. Applicable standards, the authority having jurisdiction, the utility, and qualified engineering review determine the actual requirements. The purpose of the internal check is to expose missing evidence before an output is relied upon.

Reconcile the Design With the BOM and Proposal

The review should move beyond the technical model. A customer or procurement colleague experiences the project through the proposal and equipment schedule. Check whether the module quantity, inverter type, battery scope, mounting assumptions, major exclusions, and applicable options match the current design revision.

This reconciliation catches a common failure mode: a layout was updated after a sales document was sent, but the proposal still describes the former configuration. It can also reveal more subtle problems, such as an equipment schedule based on an unavailable option or a financial scenario connected to a different system size.

Solar Proposals is the SurgePV product area for customer-ready proposal generation. It is useful when a team needs a design-derived story, but the team remains responsible for ensuring that each visible assumption reflects the intended configuration and review status.

Use a simple comparison record: current design revision, current BOM revision, current proposal version, and date each was delivered or released. If any one differs, state whether it is intentional. Silence is not reconciliation.

Record Findings as Decisions, Not Red Ink

Review comments lose their value when they become a long visual layer with no owner. Convert material comments into decisions. Each one should include the finding, the relevant evidence, the required action, the owner, the due date, and the effect on release status.

For example, “confirm service rating before final inverter selection” is better than “check electrical.” It describes the issue and stops a reader from assuming that inverter selection is final. “Update proposal after module-count change” identifies a customer-facing output that can otherwise become stale.

There are three reasonable review outcomes:

• Release for stated purpose: the package is fit for the named use, with any limitations visible.
• Release with controlled exceptions: the package can proceed only under specified conditions, each with an owner.
• Return for revision: an unresolved question affects the intended purpose too materially to release.

The second option is often the most honest. It lets a team move an indicative project forward while keeping a field or authority question visible. It must not be used to avoid a decision that the project cannot safely defer.

Protect the Review Trail Through Revisions

When a project changes, preserve the review context. The new version should identify what changed, why it changed, and whether prior findings remain applicable. A reviewer should not have to compare drawings line by line simply to discover that a roof obstruction was added or a battery option was removed.

The same rule applies to external communications. If a customer saw a concept that is no longer current, record whether a revised document was supplied and what changed in plain language. A review system works when it can answer a future question: which output did the team rely on, and what did it know at that time?

Test the Checklist on a Real Handoff

Do not validate a checklist by asking whether it looks complete. Choose an ordinary project and give the package to a colleague who was not involved in creating it. Can they identify the release purpose? Can they locate the basis for the layout and assumptions? Can they distinguish unresolved matters from accepted design choices? Can they find the owner of each exception?

If the colleague must ask for a verbal reconstruction, improve the record. The goal is not to create a longer checklist. It is to make the intended decision legible when the project moves between roles.

Practical Next Steps

1. Add a release purpose to every design-review record.
2. Review source inputs before reviewing drawing appearance.
3. Reconcile the current design, BOM, and proposal before customer or procurement release.

Frequently Asked Questions

What should a solar design review include?

Review the design basis, layout constraints, shading treatment, electrical configuration, equipment documentation, and consistency of drawings, BOM, and proposal. Then record exceptions and the package’s allowed release purpose.

Is a design review the same as engineering approval?

No. A team review can improve traceability and expose open questions. It does not replace engineering approval, local authority requirements, utility conditions, manufacturer instructions, or the work of a qualified professional.

When should a design be returned for revision?

Return it when an unresolved condition materially affects the purpose of the planned release. Examples include uncertain site geometry for a construction package, mismatched equipment records, or an electrical question that needs a qualified reviewer before the package can be used.