The 15-Point Solar Design Quality Control Checklist

A solar design can be polished, internally readable, and still be unfit for its next decision. The roof model may come from yesterday’s imagery while the drawing references an older site visit. The array may match the latest module count, but the energy model, equipment schedule, and bill of materials describe another option. A reviewer can catch dozens of small drafting issues and miss the one condition that changes whether the package should move forward.

The useful question is not “does the design look complete?” It is “what evidence supports this release, which decisions were actually checked, and what remains conditional?” A solar design quality-control checklist should produce an answer that another role can inspect without reconstructing the project from chat messages, file names, or memory.

This checklist covers the release control for a design package. It does not repeat the model-specific checks in the solar energy model quality-control checklist, the detailed intake method in the solar project intake process, or a jurisdiction’s plan-review requirements. It also does not replace engineering, structural, electrical, fire, safety, utility, permitting, manufacturer, procurement, financial, contract, or site-specific review.

The 15 points are an operating framework, not a universal code checklist or measured industry benchmark. Each company must adapt the review to the project type, design stage, location, governing documents, and qualifications of its reviewers. Where a point reaches a regulated or professional decision, the checklist should route that decision to the responsible qualified person rather than manufacture a pass.

What belongs in a solar design quality-control checklist?

A solar design quality-control checklist should cover five linked questions: whether the team is reviewing the correct project state, whether source evidence and requirements are traceable, whether technical representations agree, whether exceptions have explicit owners and consequences, and whether an authorized reviewer can release the package for one clearly stated purpose.

Treat quality control as a release decision

Quality control is not the same as correcting every imperfection. Early feasibility work can legitimately contain bounded assumptions. A construction or permit package generally needs a different evidence and approval threshold. The reviewer must know the next decision before deciding what “complete” means.

Define the release purpose in plain terms: internal feasibility, customer discussion, site-survey planning, engineering coordination, procurement review, permit preparation, installation planning, or another named use. Do not allow one approval label to migrate between purposes. “Reviewed” for sales discussion does not mean approved for construction, utility submission, or a professional seal.

The U.S. Department of Energy explains that photovoltaic modules are only one part of a complete PV system, which also involves mounting structures, power electronics, and sometimes storage (DOE solar PV system design basics). That public overview does not validate a private project. It does explain why design QC must look beyond panel placement and test the interfaces among system representations.

Use three review states instead of an optimistic checkbox:

“Not applicable” needs an owner and reason too. A blank cell cannot distinguish a deliberate exclusion from a skipped review.

Group the 15 checks around one evidence chain

The checklist follows the order in which a reviewer can establish confidence without relying on the drawing’s appearance:

The sequence is intentional. Finding a perfect equipment label does not help if the reviewer is looking at the wrong option. Comparing model output does not help if the model and released layout use different geometry. A signature does not cure an unresolved exception that the signer never saw.

What should be verified before technical design review begins?

Before reviewing geometry or equipment, verify four foundations: the release purpose and current project identity, the source evidence available at its cutoff date, the requirements and decision owners applicable to that use, and every assumption or open condition that could change an output. Hold technical checking if the governing design state cannot be identified.

1. Confirm project identity and release purpose

Write the project name, site, customer or internal identifier, design option, design stage, revision, source-data cutoff, and proposed issue purpose at the top of the review. If two options are active, give each a stable identity. Do not depend on folder location or “latest” in a filename.

The issue purpose defines the review boundary. A preliminary layout may support a site conversation while being unsuitable for equipment ordering. A permit-preparation package may still await authority review. State both what the release supports and what it does not support, especially when a downstream reader could mistake a planning artifact for a final instruction.

2. Verify the site-evidence set

Identify the imagery, survey, measurements, photographs, utility information, usage data, roof or ground condition records, obstruction evidence, and customer-supplied facts used by the design. Record their source and observation dates. The related solar site-survey evidence package describes how to preserve field evidence; this checkpoint only asks whether the released design uses the declared set.

Check for conflicts rather than choosing the most convenient source. If imagery suggests one roof feature and a later survey shows another, preserve both observations, identify which state controls, and record who resolved the difference. If verification remains pending, state the affected design decisions and the permitted use of the present representation.

3. Trace requirements, constraints, and decision owners

List the project-specific inputs that shape the design: customer scope, equipment constraints, site limits, utility information, governing documents, manufacturer instructions, internal design criteria, and jurisdiction-specific requirements identified by qualified reviewers. Do not turn this article into a universal rule set. Locations and project types differ, and current official requirements must be checked for the actual job.

NASA requirements-management guidance discusses identifying and controlling requirements, checking their sources and owners for currency, and maintaining traceability between requirements and verification (NASA requirements management). NASA does not prescribe solar practice. The operational analogy is useful: each release-changing constraint should point to a source, owner, interpretation, and visible verification result.

4. Expose assumptions, unknowns, and exclusions

Review the solar design assumptions register or equivalent project record before checking details. Separate observed facts, customer-supplied facts, modeled inputs, design choices, pending confirmations, and exclusions. For each decision-changing assumption, name the consequence if it is wrong.

Avoid a bare “to be determined” note. Write what is missing, who can resolve it, which checklist points and outputs depend on it, whether the current issue must be held or qualified, and what event triggers another review. An uncertainty that is visible and bounded can be managed. An unstated assumption quietly travels into drawings, calculations, material outputs, schedules, and customer communication.

Which technical checks belong in solar design QC?

Technical solar design QC should test seven connected representations: site geometry, placement constraints, array layout, equipment identity, electrical basis and interfaces, energy-model alignment, and drawing-to-material consistency. Each check asks whether the current evidence and scenario agree. It does not substitute a generic checklist for project-specific engineering, code, manufacturer, utility, or safety review.

5. Compare modeled geometry with current site evidence

Check roof planes or ground boundaries, scale, orientation, tilt, edges, ridges, hips, valleys, equipment areas, obstructions, and other geometry that can change placement or interfaces. The goal is not visual similarity. The goal is traceability from the released representation to current evidence.

Record the evidence used for every material correction. If a remote model cannot resolve a dimension or condition, do not smooth over the uncertainty to make the geometry look finished. Flag the affected plane or area, route verification to the appropriate site or technical owner, and state whether the present design is conceptual, conditional, or held.

6. Check access, clearance, and placement constraints

Verify that the design represents the constraints selected for this project and revision. These may include access areas, pathways, setbacks, equipment working areas, roof features, drainage, vegetation, property boundaries, easements, or operational access. This article intentionally supplies no universal distances or compliance conclusion.

The reviewer should identify the source of each applied constraint and the person qualified to interpret it. A copied template can be wrong for the project, and a clean drawing can omit a constraint that exists outside the design tool. If applicability is disputed, preserve the competing interpretations and hold the affected release decision until the responsible authority or reviewer resolves it.

7. Verify equipment identity and the evidence behind selection

Confirm manufacturer, model, rating or configuration identifiers, quantity, status, and the source documents used by the design. Distinguish proposed, accepted, approved-equal, pending substitution, and unavailable equipment states. A generic symbol should not silently become a procurement commitment.

Compatibility, listing, certification, installation, environmental, structural, and electrical questions belong with qualified reviewers using current manufacturer and project documents. QC should make those decisions visible and traceable. It should not infer compatibility because two records share a family name or because software allowed the combination to be selected.

8. Review array placement as an intentional design

Check module count, orientation, tilt, plane assignment, row spacing where relevant, obstruction interaction, edge conditions, grouping, and any excluded usable area. Compare the visible layout with the declared option and equipment basis. Ask why the arrangement changed, not only whether every module is drawn neatly.

DOE notes that mounting structures support arrays and that array orientation and tilt are design considerations (DOE design basics). That general statement does not prescribe a best layout for this project. The qualified team must consider site evidence, structural conditions, shading, electrical configuration, access, customer scope, and governing requirements together.

9. Reconcile the electrical basis and interfaces

Confirm that the electrical representation uses the same equipment, quantities, option, and design revision as the layout. Review the named system architecture, component interfaces, conductor or circuit assumptions where applicable, points of connection, service information, storage interfaces, and required notes at the level appropriate to the release.

Route calculations, protective-device choices, conductor sizing, interconnection decisions, grounding, labeling, code application, and safety conclusions to qualified personnel. A QC reviewer should never invent a missing value to complete the page. The electrical revalidation triggers help identify when a design change must return to the electrical owner.

10. Match energy-model inputs to the released layout

When the package includes modeled production, compare scenario identity, system size, module and inverter selection, orientation, tilt, shading treatment, loss assumptions, source data, and model run with the released design. The QC result is a consistency statement, not a guarantee of generation or accuracy.

Use the adjacent solar energy model quality-control checklist for a deeper review of model inputs and output limitations. On this page, the narrower test is whether the model attached to the release describes the same project option. If it does not, separate the scenarios or hold the customer-facing output.

11. Compare drawings, schedules, and material outputs

Read across the package. The plan view, equipment schedule, single-line or electrical documentation, notes, details, bill of materials, scope summary, and proposal-facing outputs should agree on decision-changing facts. Check identifiers, quantities, option names, revision references, and explicit exclusions.

A line-by-line review is not enough if each document is internally correct but belongs to a different state. Choose a small set of controlled facts and trace them everywhere they appear. If a material output is generated from the design, confirm it was regenerated after the accepted change and review unexpected differences rather than assuming automation made them correct.

How should a solar design package be controlled for release?

Control the release with four final checks: identify the exact configuration, compare intended changes across every affected output, record exceptions with owners and use restrictions, and obtain an independent review appropriate to the design stage. Release only the named revision for its stated purpose, then preserve the evidence, decision, recipients, and reopen conditions.

12. Identify the released configuration

Record the design revision, option, site-evidence cutoff, model run, equipment basis, electrical basis, material-output revision, and customer-document revision that travel together. These identifiers do not have to share one numbering system, but their relationships must be explicit.

NASA configuration-management guidance describes making product configuration known, distinguishing versions, controlling change, and verifying configuration (NASA configuration management). This is a process analogy, not a solar rule. For a design team, “current” should mean a named bundle of mutually consistent records, not whichever file has the newest timestamp.

13. Compare intended changes with actual differences

For a revised design, freeze the prior release, list the accepted changes, and compare the proposed successor against both. Every intended change should reach its dependent outputs. Every other material difference needs an explanation and reviewer. This catches both missing updates and accidental drift.

The solar design revision management guide covers change control in more depth. The QC checkpoint is simple: the successor should express the authorized changes and only the additional differences that reviewers deliberately accept. A rendering, export, or model rerun can alter content that was outside the original request.

14. Resolve or bound exceptions

An exception record needs more than a comment bubble. State the conflicting or missing condition, source records, affected outputs, decision owner, technical or commercial consequence, permitted use, due event, and closing evidence. Decide whether the package passes, releases conditionally, narrows its purpose, or remains on hold.

NASA technical-data guidance describes planning how technical data are acquired, identified, accessed, managed, and used (NASA technical data management). Again, NASA does not prescribe a solar release. The useful lesson is that review evidence must remain findable after the meeting where an exception was discussed.

15. Perform an independent release review

Use a reviewer appropriate to the stage who can inspect the evidence and challenge the preparer’s assumptions. Independence may mean another competent designer, a discipline lead, a responsible engineer, or a formal external decision-maker, depending on the item and project. Do not use the checklist to grant authority the reviewer does not possess.

NASA technical-assessment guidance discusses periodic technical reviews and technical indicators as inputs to design and management decisions (NASA technical assessment). Applied cautiously by analogy, the review should compare actual evidence against declared criteria and record the disposition. A signature without the reviewed object, scope, findings, and conditions is weak release evidence.

How do you run the 15-point design QC review?

Run the review in seven steps: freeze the candidate release, assemble its evidence index, assign competent reviewers, evaluate all 15 points as pass, conditional, hold, or not applicable, reconcile cross-document facts, dispose of every exception, and issue one bounded release record. Reopen only the affected checks when new evidence or an accepted change arrives.

A seven-step review method

1. Freeze the candidate. Assign the design option and revision. Preserve the files, data cutoff, model run, equipment basis, and outputs under review so edits cannot move the target during checking.

2. Build the evidence index. Link current site evidence, customer inputs, requirements, manufacturer records, prior decisions, assumptions, and change requests. Mark conflicting, stale, or missing records instead of choosing silently.

3. Assign review ownership. Name the preparer, checker, discipline owners, exception owners, and release authority. Define which decisions each can make for this issue purpose.

4. Evaluate all 15 points. Use pass, conditional, hold, or not applicable. Add evidence and comments at the individual point. Never allow a section-level pass to hide a failed sub-item that changes the release.

5. Trace controlled facts. Select module count, system size, equipment identity, option, model run, key electrical identifiers, material quantities, assumptions, and revision references as applicable. Compare them across drawings and outputs.

6. Dispose of exceptions. Correct the source, revise dependent outputs, obtain missing evidence, or record a bounded condition. Route engineering, code, utility, safety, manufacturer, structural, electrical, financial, procurement, contract, and legal decisions to qualified owners.

7. Issue and preserve the release. State purpose, permitted uses, restrictions, open conditions, reviewers, approval boundaries, recipients, and reopen triggers. Keep the QC record with the exact configuration it reviewed.

Copy-ready solar design QC record

Copy this table into the team’s project system. Add project-specific subchecks rather than treating these 15 rows as a complete jurisdictional or engineering standard.

Add these release fields beneath the table: project and site; candidate id; release purpose; source cutoff; design option and revision; model, electrical, material, and proposal references; reviewers and authority boundaries; unresolved conditions; permitted uses; prohibited uses; known recipients; release date; and reopen triggers.

Illustrative example, not a customer case

A commercial rooftop design is prepared for a customer discussion. The candidate layout uses a newer site survey and removes one roof area that earlier imagery treated as usable. The module count and plan view are current, but the attached energy-model run and material output still belong to the prior option. Equipment compatibility review is pending, and the drawing note says “final.”

The team freezes the candidate and labels its intended use as customer option review, not construction, procurement, permit, or utility submission. Points 1 through 8 can be evaluated against the new evidence. Point 9 remains conditional or held by the qualified electrical owner. Points 10 and 11 fail consistency because model and material records describe another layout. Point 14 records the equipment question and affected outputs. Point 15 cannot pass until the release authority sees those dispositions.

The correction is not to copy the new module count into every document. The model owner evaluates the current geometry and assumptions, the material output is regenerated and reviewed, the equipment owner resolves or bounds compatibility, and the misleading “final” note is replaced with the actual issue purpose. The successor package then receives stable identifiers and a review record.

No production, compatibility, approval, schedule, savings, or customer result is assumed in this example. Its purpose is to show how one current drawing can coexist with stale dependent outputs and why a release decision must follow the evidence chain.

When should a solar design stay on hold?

Hold a solar design when the governing project state is unclear, current evidence conflicts, a requirement lacks an authorized interpretation, a decision-changing assumption is hidden, technical representations describe different options, an exception lacks an owner, or the designated reviewer cannot support the intended use. Narrow or qualify the release only when responsible owners explicitly permit that boundary.

Diagnose the failure instead of adding another checkbox

Repeated defects often signal a control problem upstream. A missing note can be corrected locally. A note that returns after every revision may indicate the wrong template, source, owner, generation path, or approval step. Record the cause and its containment so quality work does not become endless proofreading.

Do not reward a low defect count if the review missed the release-changing issue. Nor should the team hold a design indefinitely because an immaterial field is imperfect. The release authority must connect severity to the stated use, the affected decision, available evidence, and the competence of the owner making the disposition.

Keep software inside the review boundary

Within the SurgePV solar design workspace, the recorded product scope covers roof modeling in 3D, array-layout and shading tools, energy-yield and financial models, electrical-workflow support, material outputs, and proposal generation. Its results remain dependent on source data, assumptions, equipment models, configuration, and review (SurgePV product source).

Connected outputs can help a team compare one project state across design and customer documents. They do not prove external evidence, choose governing requirements, interpret local rules, resolve a disputed site condition, establish equipment compatibility, exercise professional judgment, or authorize use. Outputs do not replace approval by the responsible engineer, authority, lender, insurer, utility, or another qualified decision-maker.

After release, preserve the QC record with the candidate it evaluated. If a site fact, customer decision, design constraint, equipment state, model input, electrical decision, or intended use changes, reopen the affected points and their consumers. Do not erase the earlier disposition. The change history explains why a once-valid release no longer carries the next decision.

Frequently Asked Questions

What is the first solar design quality-control check?

Confirm the release purpose and governing design basis before checking individual drawing details. The reviewer should know the project, site, option, source-data cutoff, design revision, intended use, applicable requirements, and decisions that remain outside the review. Otherwise, a technically careful check can still approve the wrong option or an outdated source state.

Does every open item require a solar design hold?

No. The qualified release owner should decide whether an open item is decision-changing for the stated use. Record it as accepted for this stage, conditionally releasable, or blocking, with a reason, owner, due event, affected outputs, and reopen trigger. A blank field or undocumented assumption is not a release decision.

Who should perform the final solar design QC review?

Use a reviewer with the competence and authority required for the design stage and decision. Separate preparation, technical checking, commercial acceptance, and formal approval when those roles differ. A checklist does not grant qualifications, and software completion does not replace review by the responsible engineer, authority, utility, insurer, lender, or other decision owner.

Should solar production modeling be part of design quality control?

Yes, when modeled output is part of the released package, but the QC question is alignment rather than a promised result. Confirm that geometry, equipment, orientation, shading treatment, loss assumptions, source data, and scenario identity match the released design. Then route model-method questions to the qualified production reviewer.

Can solar design software approve a design for release?

No. Software can support roof modeling, array layout, shading analysis, energy-yield modeling, electrical workflows, material outputs, and proposal generation. People still must verify external evidence, choose requirements, resolve exceptions, apply jurisdiction-specific rules, exercise engineering judgment, and authorize the release within their roles. External decision-makers retain their own approval authority.

A dependable QC record does not claim that uncertainty disappeared. It shows which configuration was reviewed, which evidence supported the decision, what remains conditional, who owns the next action, and what would reopen the release. That is enough for the next person to use the design without mistaking a clean page for an unlimited approval.