7 AI Solar Design Mistakes Human Review Must Catch

A roof model can look unusually clean at the exact moment the project record is most uncertain. The planes meet. Modules sit inside tidy boundaries. A production figure appears beside the layout. The file feels finished because the visual gaps have disappeared. Yet the source image may be old, a vent may be represented as a harmless bump, an equipment revision may not have reached the electrical work, or a default loss may be carrying more weight than anyone realizes.

That is the uncomfortable part of AI-assisted solar design: presentation quality and evidence quality are different things. A reviewer is not there to admire the output or prove that the tool failed. The reviewer is there to decide whether each material object and assumption is supported for the next release. The broader AI-assisted solar work guide covers governance across the workflow. This page stays narrower. It is a defect-finding and release-control method for the design output itself.

The NIST AI Risk Management Framework is voluntary and addresses trustworthiness considerations in the design, development, use, and evaluation of AI systems. Its companion AI RMF Playbook organizes voluntary suggestions around Govern, Map, Measure, and Manage. Neither source validates a solar design or prescribes this checklist. NIST notes that AI RMF 1.0 is being revised and that the Playbook will follow that revision. Use the current voluntary guidance to define context, examine evidence, track risk and assign decision responsibility.

Use this workflow guide to review an assisted draft for its stated purpose. Automated checks may flag invalid inputs or conflicts, but they do not establish complete evidence, applicable compliance or project approval. Retain field verification and qualified decisions appropriate to the project.

Which AI-assisted solar design mistakes require human review?

Human reviewers should look for seven failure modes: weak source identity, false roof certainty, incomplete exclusion zones, unsupported shading context, disconnected equipment and electrical choices, modeled output presented without visible assumptions, and version drift across deliverables. The point is not to predict what AI will get wrong. It is to inspect what the next decision actually depends on.

Mistake 1: reviewing the picture before verifying the source

The first question is not whether the roof outline looks plausible. It is whether the reviewer knows what evidence produced it. Confirm the project identifier, address or parcel context, building selection, source type, capture date where available, processing date where available, coverage, quality indicator, coordinate reference where relevant, and the reason this evidence is appropriate for the current design stage.

First-party Google Solar API data-layer documentation shows why source metadata matters. Google documents a digital surface model, aerial imagery, masks, solar flux, hourly shade, imagery dates, processing dates, and an imagery-quality field. That list describes what its own service can return; coverage and the requested data subset still matter. Google also flags content restrictions for developers with EEA billing addresses under its applicable terms. It does not prove that any particular layer is current, complete, suitable for a project, or consistent with the field condition.

A reviewer should place the evidence beside the model, not in a separate inbox. If two roof candidates share a similar address, if the parcel contains several structures, if an addition appears only in newer field photos, or if tree work has changed the skyline, the output must not choose a truth by visual confidence. Record the conflict and return it to the owner who can reconcile identity and recency.

The practical defect statement is specific: “The model uses source set A, while the site record shows condition B, and the difference affects decision C.” Avoid writing “AI may be wrong.” That phrase identifies neither the object nor the blocked decision. A usable return identifies the roof plane, obstruction, boundary, or source field that must be resolved.

Mistake 2: treating modeled roof geometry as verified site geometry

A roof model is a representation assembled for a purpose. Human review must separate visible geometry from inferred geometry and verified geometry. For each plane, trace the evidence for outline, ridge, hip, valley, eave, slope, orientation, height relationship, and any surface that affects placement. Then mark which fields came from remote data, survey, field measurement, as-built record, or reviewer assumption.

The U.S. Department of Energy’s photovoltaic system design overview describes modules as one part of a connected system that also includes mounting, orientation, inverters, storage, and other technologies. That public overview does not establish a roof’s dimensions or capacity. It does show why a small geometric discrepancy can move into mounting, array orientation, equipment selection, and later documents.

Do not ask a remote model to answer a condition it cannot observe. Roof covering condition, concealed structure, attachment suitability, drainage behavior, deterioration, access, and other field-dependent conditions may require records or qualified inspection outside the model. The exact verification route depends on the project, jurisdiction, contract, company process, and release. This article does not establish a universal site-visit or engineering rule.

Use a confidence label tied to evidence, not a color that implies certainty. “Remote source only,” “field dimension supplied,” “survey reconciled,” and “qualified review pending” are more useful than green, amber, and red without definitions. A reviewer should be able to open the label and find the source, date, person, and limitation behind it.

Mistake 3: accepting a clean layout with incomplete exclusions

An array can fit geometrically and still be unready for release. Exclusions may come from observed roof objects, access and maintenance needs, equipment clearances, drainage, owner requirements, applicable fire or building review, utility requirements, manufacturer instructions, and qualified structural or electrical decisions. The reviewer should not assume one generic offset applies everywhere or that an omitted object is harmless.

Build an obstruction and exclusion register. Give each object a stable id, source, observed footprint, vertical context if known, effect on placement or access, responsible owner, and disposition. Where applicable requirements control the final boundary, cite the current project-specific source and reviewer. Do not transform a house rule, old template, or remembered requirement into a universal code statement.

Look for suspicious regularity. Equal gaps around unlike objects, a perfectly continuous edge across an uncertain roof transition, modules placed through a visually ambiguous feature, or a boundary that changes without a corresponding issue record all deserve attention. None proves an error by itself. Each is a prompt to compare the object with evidence.

Safety-related conditions need real owners. OSHA’s recommended safety-program practices describe a proactive approach organized around seven core elements. That resource does not create a site plan. It supports the narrower point that a drawing cannot silently stand in for the employer, competent person, contractor, or qualified reviewer responsible for the applicable hazard decision.

Mistake 4: treating a shade visualization as complete site context

A shade layer is an output of selected geometry, obstruction, time, weather, and model inputs. Review it by tracing those inputs, not by deciding whether the colors look reasonable. Compare the obstruction inventory with the model. Check the source date. Identify vegetation, neighboring structures, roof features, and horizon conditions that may have changed or remained uncertain.

DOE’s solar radiation guide says radiation at a location varies with geography, time, season, local landscape, and local weather. Sandia PVPMC’s modeling guide for shading, soiling, and reflection losses treats those items as reductions applied within a performance-modeling workflow. Those sources do not validate a project’s weather file, obstructions, loss values, or output.

Ask four plain questions. What physical condition does the model represent? Which source establishes it? Which important conditions remain absent or assumed? What release is appropriate until those gaps are resolved? The answers should sit beside the production output so the customer-facing document cannot detach the number from its context.

A shading review also needs change sensitivity. If trimming, removal, construction, roof work, equipment movement, or a revised layout changes the modeled condition, identify which outputs must be rerun and which documents must be refreshed. Do not merely update the image. Link the changed input to the successor model and preserve the earlier version for comparison.

Mistake 5: checking equipment fields without checking relationships

Individual data fields can be correct while the design relationship is wrong. A selected module may match the equipment library, an inverter may have a current data sheet, and a string count may look orderly. Human review still must examine whether the equipment revision, array arrangement, electrical assumptions, environmental design basis, manufacturer limits, and downstream documents belong together.

This is where “looks complete” becomes dangerous. The layout, equipment schedule, stringing work, bill of materials, and single-line representation may have been produced or revised at different times. Reviewers should reconcile stable equipment identifiers, manufacturer and model, revision or source date, quantity, electrical parameters used by the qualified designer, substitution status, and the design version that consumes each value.

Use the solar stringing review checks for the narrower electrical handoff and the layout, equipment list, and SLD consistency guide for cross-document parity. This article does not supply project string limits, conductor decisions, protective-device selections, or code conclusions.

Return the whole affected relationship, not only the first wrong field. If a module substitution changes electrical, mechanical, procurement, production, labeling, or customer-facing work, the return record should name every artifact that requires revalidation by its responsible owner. A silent library replacement is not a completed change-control process.

Mistake 6: presenting modeled output without its decision context

An annual production figure can travel farther than its assumptions. Once copied into a proposal, financial model, sales deck, or contract discussion, it may look like a measurement or promise even when it began as a preliminary scenario. Human review must keep the selected weather data, geometry, shading, loss assumptions, equipment model, system configuration, exclusions, and intended use attached to the output.

Classify each important value as observed, supplied, selected, modeled, calculated, reviewed, or approved. These labels answer different questions. “Modeled” says the value came from a model. It does not say the inputs were verified, the method was appropriate, the result was approved, or the project will achieve it. “Reviewed” should name the review scope and person rather than imply unlimited validation.

Ask what decision the value is allowed to support now. A preliminary comparison may tolerate explicitly labelled assumptions that a procurement release, permit package, customer commitment, lender package, or construction instruction cannot. The responsible technical, commercial, finance, legal, utility, permitting, lender, insurer, and customer reviewers must set those boundaries where applicable.

The strongest review note is close to the number: source set, model version, scenario, material assumptions, exclusions, review state, and next verification. A generic disclaimer at the end of the page does not repair an unsupported claim in the middle. The solar design review checklist provides a broader technical review framework when the package has advanced beyond an initial assisted draft.

Mistake 7: letting versions disagree while every document looks finished

Version drift is not always obvious. The layout may contain the newest module placement while the bill of materials retains the old quantity. The electrical representation may use a previous equipment choice. The production model may reflect an earlier azimuth or obstruction set. The proposal may still show the image and narrative approved before the last design return.

NASA’s configuration-management reference describes the discipline as providing visibility into and control over changes to performance and functional and physical characteristics across a product life cycle. NASA does not prescribe solar workflow. The transferable idea is traceability: identify the controlled object, record the change, report its status, and verify the resulting configuration.

Create one release manifest for the package. Record the project id, release purpose, design revision, evidence snapshot, equipment revision, model run, layout, equipment schedule, electrical document, BOM, proposal or customer visual, open exceptions, approvers, and issue date. Every artifact should point back to the same manifest or show why it is intentionally outside the release.

Do not “fix” drift by renaming files at the end. Reconcile the underlying objects. A document can carry the newest filename and still contain stale equipment, assumptions, or geometry. Review the change history and a small set of critical fields across artifacts, then return any mismatch to the owners of both the source object and the dependent document.

What evidence is needed before reviewing an assisted design?

The reviewer needs a project identity record, source and field evidence, design-basis assumptions, equipment references, model configuration, applicable requirement sources, change history, requested release, and named decision owners. Evidence should be versioned and accessible beside the draft. If a material input is absent, review should identify the blocked decision rather than fill the gap from memory.

Start with a review cover sheet. It should define the purpose of this draft: lead-stage concept, site-assessment preparation, technical design, customer proposal, permit-support package, procurement input, construction handoff, or another company-defined state. The same drawing may be adequate for one conversation and inadequate for another. Review criteria must follow the release, not the aesthetic finish.

Evidence needs provenance. “From the customer” is not enough when the source could be an old sketch, forwarded photo, utility document, salesperson note, or field measurement. Preserve the original file or system record, capture date if available, submitter, affected object, transformation, and reviewer limitation. If privacy, contract, or access controls restrict retention, follow the company’s qualified policy rather than copying data into an uncontrolled checklist.

Separate facts from planning assumptions. A supplied roof dimension may still require reconciliation. A selected equipment model may be a proposal candidate rather than an approved procurement item. A jurisdiction field may identify the location without identifying every applicable requirement. Labels should describe evidence state, not award confidence.

Finally, verify reviewer scope. A layout reviewer may be able to identify a geometry conflict without being authorized to decide structural capacity, code compliance, utility acceptance, or safety control. An effective workflow makes that boundary normal. Escalation is not a review failure. It is the correct result when the decision belongs somewhere else.

How should a human review and release the design?

Use an eight-step sequence: freeze the review package, reconcile identity and evidence, inspect roof geometry, verify exclusions and shading context, reconcile equipment and electrical relationships, audit model assumptions, compare every dependent document, and issue a recorded release or return. Each step needs an owner, evidence link, disposition, and successor action. Approval is never inferred from silence.

1. Freeze the review package. Assign a review id and lock the design revision, source snapshot, equipment set, model run, and dependent documents. New information can enter as a successor revision, not as an invisible mid-review change.

2. Reconcile project identity and evidence. Confirm the intended site, structure, scope, source dates, field records, and requested release. Stop if reviewers cannot tell what physical condition the model represents.

3. Inspect roof geometry object by object. Trace each material plane, edge, roof transition, slope, orientation, height relationship, and ambiguous surface to the available evidence. Mark what remains inferred or requires qualified verification.

4. Verify obstructions, exclusions, and shade context. Compare the obstruction register with imagery and field evidence. Confirm that access, clearances, applicable requirements, vegetation, neighboring features, and other project-specific constraints have assigned owners.

5. Reconcile equipment and electrical relationships. Compare the approved candidate equipment, revisions, quantities, layout, stringing work, electrical document, manufacturer information, and required qualified review. Return relationships, not isolated cells.

6. Audit the model configuration and claim boundary. Record the weather source, geometry, shade context, losses, equipment model, scenario, model version, and intended use. Keep output visibly modeled and prevent unsupported customer, finance, or performance promises.

7. Compare every dependent artifact. Check the layout, equipment schedule, electrical representation, bill of materials, proposal visual, production output, customer language, and change record against the same release manifest. Use the design revision impact checklist when a change crosses functions.

8. Issue a recorded disposition. Choose return, hold, conditional internal use, approved for a named next stage, or another company-defined state. Name the reviewer scope, unresolved items, next owner, expiry or change trigger, and external approvals still required.

The sequence should not become one reviewer clicking every box. Assign the object to the person who has the evidence and authority. A design operator can prepare the package. A site owner can reconcile field evidence. Qualified technical reviewers can decide the fields assigned to their competence. Project, procurement, finance, customer, safety, legal, utility, permitting, lender, insurer, and external authority decisions remain with their respective owners.

What happens when evidence is missing or the design changes?

Missing evidence should create a named hold, return, or restricted-use state tied to the decision it blocks. Record the affected object, current evidence, gap, owner, required next input, and retest condition. When a design changes, trace the change to every dependent model and document. Never close an issue merely because the new output looks plausible.

A useful return reason is observable and actionable. “Bad AI output” is neither. It encourages the next person to regenerate the same uncertainty. “North roof-plane boundary conflicts with the dated field sketch and blocks final module placement” identifies the object, conflict, evidence, and decision.

Do not hide a hold in comments. Give it a state visible to the person trying to release the project. If the workflow allows conditional internal use, name the exact allowed purpose and forbidden downstream use. For example, a remote concept might support a preliminary discussion while remaining prohibited for procurement, construction, permit, utility, lender, insurer, or customer guarantee decisions.

Retest narrowly but completely. Repeat the failed check, then inspect the dependents that the correction could disturb. Correcting a roof edge may affect placement, count, shading, model output, BOM, electrical work, and customer imagery. Correcting an equipment choice may affect still more. The change record should carry those dependencies forward instead of expecting each department to notice independently.

Copy-ready AI-assisted solar design review record

Use one record for each frozen review package. Adapt roles and states through qualified company review. Empty fields are not approvals.

The record is intentionally uncomfortable when evidence is missing. That discomfort is information. A blank field makes the gap visible before a persuasive drawing or production number travels into a commitment.

Illustrative workflow: one corrected roof object changes connected outputs

Illustrative workflow, not a customer case or measured result. A design operator freezes a preliminary assisted layout and links the remote source metadata, field-photo set, equipment candidate, shade model, and proposal draft. The package is explicitly limited to internal review.

During geometry review, a reviewer finds that one roof object is represented differently in the model and in a dated field photo. The available records do not establish the object’s dimensions or present condition. The reviewer does not delete it, estimate around it, or declare the model wrong. The reviewer creates a geometry hold that identifies the object, conflicting evidence, affected modules, blocked release, and field owner.

The field owner supplies accepted evidence under the company’s procedure. The successor model changes the object boundary. That change removes and relocates proposed modules, so the design owner opens dependent checks for the layout, shade model, equipment quantity, BOM, electrical work, production output, and proposal image. Each artifact receives a successor version linked to the same change record.

The model owner reruns the applicable scenario with recorded inputs. Qualified electrical and other technical reviewers revalidate the fields within their scope. The proposal owner replaces the stale visual and keeps modeled-output limitations beside the updated value. The release manifest shows which reviews are complete and which external decisions remain pending.

The evidence supports a bounded workflow conclusion: one unresolved object triggered a hold and a controlled successor review. It does not support a statement about AI accuracy, avoided rework, time saved, production, customer response, compliance, or approval.

Where does SurgePV fit, and where must people take over?

SurgePV can support 3D roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation within a connected project record. Qualified people must still validate evidence, decide technical and safety questions, control customer claims, review changes, and obtain every required engineering, authority, utility, lender, insurer, and other approval.

The product boundary matters more in this article than a feature list. SurgePV’s solar design workflow can help a team keep the roof model, layout, shading work, modeled output, electrical workflow, material output, and proposal process closer together. In a demonstration, trace one changed input through its dependent outputs and confirm which review states or ownership records your team must manage separately.

Results depend on source data, assumptions, equipment models, configuration, and review. SurgePV does not establish that imagery is current, verify a concealed site condition, make a structural or electrical judgment, perform a site-specific hazard assessment, interpret every applicable requirement, approve customer language, or replace the responsible engineer, authority, utility, lender, insurer, employer, contractor, or other decision owner.

Keep three roles distinct. Software prepares and connects work within its verified scope. Reviewers inspect evidence and make only the decisions within their competence and authority. External parties decide the approvals and conditions assigned to them. A workflow fails when one role silently borrows authority from another.

Frequently Asked Questions

Can AI approve a solar design after it generates a layout?

No. An AI-assisted or automated output is a draft within a controlled workflow, not an approval. The responsible people must verify source evidence, assumptions, geometry, equipment relationships, modeled outputs, and document parity. Qualified engineers, authorities, utilities, safety owners, lenders, insurers, and other reviewers retain the decisions assigned to them.

What should a reviewer check first in an AI-assisted solar design?

Check identity and evidence before inspecting the drawing. Confirm the site, building or parcel, imagery date and quality, survey or field records, equipment revision, applicable project stage, requested deliverable, and current design version. A precise review of the wrong address, stale image, or superseded configuration is still a failed review.

Does human review require a site visit for every solar design?

This article does not set a universal site-visit rule. The required verification method depends on the project stage, available evidence, company procedure, site conditions, jurisdiction, contract, and decisions being released. When remote evidence cannot resolve a material condition, the reviewer should return the item to the qualified owner rather than assume it away.

How should a team document an unresolved AI-assisted design issue?

Record the affected object, source evidence, observed conflict, decision it blocks, severity or release impact, named owner, required next evidence, return reason, and retest condition. Keep the issue linked to the design version. Do not close it because a later drawing looks cleaner; close it only when the specified evidence supports the disposition.

Where can SurgePV support AI-assisted solar design review?

SurgePV supports 3D roof modeling, solar array layout, shading analysis, energy-yield and financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. Results still depend on source data, assumptions, equipment models, configuration, and review. SurgePV does not replace field verification, engineering judgment, safety control, compliance review, or external approval.

Choose one assisted draft and complete its review record before release. Resolve each blocked decision or state its restricted use, then retain the reviewer’s scope and successor revision with the outputs.