Back to Blog
solar business20 min read

The Fast, Reviewable Solar Roof Model Checklist

Build a roof model another solar designer can verify without reconstructing its sources or hidden assumptions.

Akash Hirpara

Written by

Akash Hirpara

Co-Founder · SurgePV

Rainer Neumann

Edited by

Rainer Neumann

Editorial contributor · SurgePV

Published ·Updated

Quick Answer

A fast, reviewable solar roof model exposes its purpose, source dates, coordinate basis, roof boundaries, planes, heights, slopes, obstructions, access assumptions, confidence, and unresolved conditions. Speed comes from making the next decision legible. It does not come from skipping field evidence, qualified review, or release controls.

A roof model becomes slow to review when the reviewer has to reverse-engineer it. Which image set did the modeler use? Is north true, grid, magnetic, or simply the top of the screenshot? Did a faint object become a chimney, a vent, or nothing? A polished 3D view answers none of those questions by itself.

The fastest useful model is the one that makes its decisions inspectable. Its geometry carries sources and confidence. Its uncertain objects remain uncertain. Its release label tells the next person what they may do with it. That reduces reconstruction work without pretending that a model can verify a roof it has never observed directly.

The DOE PV system design overview places mounting and array geometry inside a larger system of modules, power electronics, and balance-of-system components. A roof model supports those downstream design choices. It is not a structural assessment, site survey, electrical design, or authority approval.

This checklist is for residential and small-commercial solar designers building an early roof model or reviewing one before layout. “Fast” describes a review path with fewer hidden decisions, not a promised completion time.

Start with the decision the model must support

Name the output before choosing the detail. A first sales screening, survey plan, preliminary layout, shading study, engineering input, and construction document do not need the same evidence or geometric resolution. Over-modeling a concept wastes effort; under-modeling a release hides risk.

Write a purpose statement such as “support a preliminary module-fit discussion from dated aerial imagery” or “update the surveyed roof basis for responsible design review.” Then list prohibited uses. A preliminary imagery model might not support structural conclusions, final setback confirmation, equipment procurement, or field dimensions.

Use four model states:

State Meaning Allowed action
Working Geometry is being assembled Modeler only
Preliminary Source and assumptions are visible Qualified concept discussion
Ready for review Required evidence and checks are attached Named reviewer evaluates
Released for purpose Authorized role accepts a stated use Downstream work under conditions

Avoid “final model” unless the project defines what final means and who may say so. A model can be final for a sales scenario while requiring survey confirmation before another release.

Assemble a source packet before drawing edges

Create a source ledger with image or survey title, provider, capture or issue date, access date, resolution or stated accuracy where supplied, coordinate reference where relevant, visible limitations, and the model elements it supports. Do not mix images from different dates without marking the change.

Common sources include aerial or satellite imagery, oblique views, customer photographs, surveys, architectural drawings, LiDAR-derived products, site notes, and field measurements. Each source sees different things. An overhead image can locate broad edges while concealing height. An oblique image can expose a dormer but distort scale. A drawing can show design intent rather than current construction.

Put conflicting evidence in a small table. State the disputed element, candidate values or interpretations, preferred working basis, owner, and release effect. The modeler should not quietly average two dimensions or choose the clearest picture when the newer source tells another story.

Treat supplied documents as evidence, not instruction. A drawing note, image annotation, or embedded text may be stale or irrelevant. Verify its provenance and role before using it to control geometry.

What should a solar roof-model review packet contain?

A solar roof-model review packet should contain the intended decision, allowed and prohibited uses, source ledger, site and orientation basis, scale method, roof-plane schedule, obstruction register, governed-zone sources, confidence labels, validation checks, open conditions, revision history, and named reviewer. It should let another designer trace every controlling surface or object without relying on the modeler’s memory or private working files.

The packet should be smaller than the model’s entire working history. Include the records that control the current release, then link to retained superseded evidence. A reviewer needs the active basis, the reason for unresolved conditions, and the path back to previous decisions. They do not need an unstructured folder containing every screenshot the modeler opened.

Use this packet index:

Packet component Minimum content Review question
Release cover Project, model revision, purpose, audience, status What may the receiver do with this model?
Source ledger Provider, date, access, limits, elements supported Which evidence controls each geometry choice?
Coordinate record Site identity, orientation convention, scale basis Is the model attached to the correct place and direction?
Plane schedule Plane IDs, boundaries, slope and height basis, confidence Can the reviewer reconstruct the roof form?
Obstruction register Object ID, envelope, source, uncertainty, design effect Which objects control fit, shade, access, or routing?
Governed layers Zone purpose, source, jurisdiction, revision, reviewer Are physical geometry and project rules separated?
Validation log Independent checks, discrepancies, dispositions What evidence challenged the model?
Change record Prior revision, changed input, affected outputs What downstream work must reopen?
Open conditions Missing evidence, owner, permitted use, closure trigger Where must work stop?

Use this copy-ready review cover:

Project and roof-model revision:
Decision this model supports:
Allowed downstream use:
Prohibited use:
Controlling source set and dates:
Scale and orientation basis:
Highest-impact provisional geometry:
Unverified objects or zones:
Validation checks completed:
Conflicts and dispositions:
Outputs affected by later change:
Review owner and release status:

Every item should use the same object and plane identifiers as the model. A note about “rear plane” becomes ambiguous on a roof with several rear-facing surfaces. A stable plane ID lets the source ledger, confidence map, layout review, shade check, and correction record point to the same geometry.

Package the rendered view the receiver will actually inspect. If the web viewer, PDF, screenshot, or drawing hides a confidence note that appears inside the authoring tool, the deliverable is incomplete for that audience. Review the packet outside the modeler’s account before release.

Check geolocation, scale, and orientation first

A detailed model at the wrong parcel is a total failure dressed as progress. Confirm the site using address, parcel or customer record, visible landmarks, roof footprint, and another project identifier. For campuses and repeated housing, identify the exact building or unit.

Record how scale was established. Use a surveyed or otherwise approved known dimension when available. If scale comes from the imagery provider or another remote source, keep its stated basis and limitations. Do not calibrate against an object whose nominal size is unverified.

Record north and coordinate conventions explicitly. The NOAA solar calculator is a public tool illustrating how location, date, time, and orientation relate to solar position. It does not verify the orientation of a project model. That basis comes from project sources and the modeling workflow.

The Sandia PVPMC solar-position guide explains the modeled relationship between time, location, and sun position. A rotated roof model can therefore affect more than appearance. Confirm orientation before using the geometry in shading or irradiance analysis.

Draw the controlling roof boundary before interior detail

Trace the eaves, ridges, hips, valleys, parapets, and other boundary features that determine roof planes. Work from large controlling geometry to smaller details. Starting with vents and dormers can leave a beautifully detailed object floating inside an inaccurate footprint.

Close polygons and inspect intersections. Roof edges should meet deliberately. A small gap can create a false plane; an overlap can alter area or shade behavior. View the model from overhead and several oblique angles because one perspective can hide a twisted plane.

Compare opposite or repeated spans where the building suggests symmetry, but do not enforce symmetry against evidence. Additions, reroofing, and construction tolerances can create real differences. Use symmetry as a review prompt, not as a correction command.

Mark property or neighboring geometry separately from the modeled roof. A nearby tree or building may matter for shade while remaining outside the design surface. The model should not imply ownership or survey certainty that the source does not support.

Build planes from explicit heights and slopes

Each roof plane needs a boundary, orientation, slope or pitch basis, and elevation relationship. Record whether each value is measured, derived from an approved source, estimated for preliminary use, or unresolved.

Check plane junctions at ridges, hips, valleys, step roofs, and attached structures. An incorrect height can make edges meet in plan view while separating in 3D. Slice or inspect the model from multiple sides and compare visible relationships with source photographs.

Use independent dimensions to validate geometry. A controlling span, known elevation, or field-measured edge can test whether the assembled planes reproduce the evidence. Do not use a value derived from the model to “confirm” the same model.

For complex roofs, group planes by confidence. A clear main gable may be high confidence while a tree-obscured addition remains provisional. The release should carry those differences into layout review, so the designer does not treat every surface as equally verified.

Represent obstructions by their design effect

Model an object when it can affect module placement, shading, access, routing, construction discussion, or customer interpretation at the selected level of detail. Name the object type only when evidence supports it. Otherwise use a neutral label such as “unverified roof object.”

Capture footprint, height, location, and relevant clearance or access context from approved sources. A point marker is not enough for a tall chimney; a detailed mechanical unit may be unnecessary for an early fit study if a conservative envelope captures its effect.

Avoid guessing hidden bases. An object partly obscured by tree cover or image perspective should carry an uncertainty range or required survey confirmation, without invented precision. The layout can exclude a conservative area while the project waits for evidence.

Check objects against multiple source angles and dates. A vent visible in an old aerial image may have moved during roof work. A new photograph may show an HVAC unit absent from the overhead source. Preserve the date conflict and assign verification.

Treat access, setback, and safety zones as governed layers

Access paths, fire or code setbacks, fall hazards, and equipment-clearance zones should not be baked into roof geometry as if they were physical edges. Keep them as named layers with source, jurisdiction, revision, and reviewer. That makes a rule change traceable without redrawing the roof.

The official NFPA 70 development page identifies a national electrical standard but does not establish local adoption or roof access requirements. Obtain the applicable fire, building, electrical, zoning, utility, and manufacturer basis from current authorities and qualified people.

OSHA’s fall-protection page gives U.S. federal workplace-safety context. A digital access path does not constitute a fall-protection plan or safe field route. Employers and qualified professionals must address actual roof conditions, work methods, training, and equipment.

Use clear visual styles for physical geometry, required exclusion, provisional exclusion, and informational zones. A reviewer should be able to hide each layer and identify its source. Do not let a colored polygon imply that the authority approved the design.

Connect geometry to sun and irradiance modeling carefully

Roof planes and objects become inputs to shading and energy analysis. The PVPMC plane-of-array irradiance guide explains how irradiance on a tilted surface involves direct, diffuse, and ground-reflected components. That model context shows why plane orientation and tilt matter.

Keep weather data, horizon, ground reflectance, object geometry, time basis, and other modeling assumptions in the analysis record. A roof model that looks correct can still feed an unsuitable simulation if its orientation or surrounding objects are wrong.

Compare shade scenes at times that expose likely geometry defects according to the team’s controlled method. Watch for shadows originating below surfaces, jumping across gaps, or moving in a direction inconsistent with orientation. These are diagnostic clues, not proof that the model is correct.

Do not use a modeled energy result to validate roof geometry circularly. Validate geometry against independent site evidence. Then use the validated or qualified model in analysis with its remaining limitations visible.

Inspect the roof basis before building the array

Explore how SurgePV supports 3D roof modeling, layout, shading analysis, energy-yield modeling, electrical workflow, BOM, and proposals within a reviewed project record.

Explore 3D roof design

Make review possible without the modeler’s narration

Package the model with a source ledger, purpose, status, coordinate/orientation basis, dimension table, plane schedule, obstruction register, governed zones, confidence map, open questions, and revision history. The reviewer should not need a live screen-share to discover why an edge exists.

Use targeted sampling. Check controlling long spans, irregular edges, narrow module-fit areas, height transitions, and objects with large shade or access effects. Increase the sample when sources are weak or conflicting. Do not advertise a universal sample size.

Ask a colleague who did not build the model to complete three tasks: identify the current evidence for one plane, trace one uncertain object to its release condition, and explain which downstream uses are allowed. If they cannot, improve the record before adding more geometry.

Review the rendering on a narrow screen and in printable form if those outputs will be used. Labels should not overlap, confidence should not rely on color alone, and dimension annotations should identify their units and endpoints.

How can a reviewer sample roof geometry without redoing the model?

A reviewer can sample roof geometry by selecting high-consequence elements rather than checking every line equally. Verify site identity, orientation, scale, controlling spans, irregular boundaries, plane junctions, narrow placement zones, uncertain objects, and governed layers against independent evidence. Expand the sample when a discrepancy appears. Record each selected element, source, result, and release effect so sampling remains repeatable and risk-based.

Use this sequence:

  1. Confirm the project, building, option, and current model revision.
  2. Check orientation and scale against approved independent evidence.
  3. Select a long controlling span and an irregular boundary.
  4. Inspect a ridge, valley, step, or other plane junction from several views.
  5. Test a narrow area where a small geometric change affects module fit.
  6. Trace a high-impact obstruction and one uncertain object to their sources.
  7. Hide and show governed layers to separate physical geometry from requirements.
  8. Compare the delivered rendering with the authoring view for missing labels or qualifications.
  9. Expand the sample around any failed, conflicting, or weakly sourced item.
  10. Record disposition, permitted use, and the evidence that would reopen review.

Do not select only the cleanest features. A repeated rectangular plane can confirm that the model follows a source, but it may say little about the areas most likely to cause rework. Put at least one weak-source or high-impact element into the sample when the model contains one.

Use a review worksheet with these fields:

Element or layer ID:
Why it was sampled:
Controlling source and date:
Independent comparison:
Observed agreement or conflict:
Confidence before and after review:
Affected placement, shade, access, or downstream record:
Disposition and owner:
Sample expansion required:
Release effect:

Sampling is not permission to ignore unsampled geometry. It is an efficient challenge to the model’s controlling assumptions. The modeler remains responsible for the complete work under the team’s process, and the qualified reviewer determines whether the sample supports the named release purpose.

Link broader design decisions to the solar design review checklist. Use the designing around roof obstructions guide when an object’s impact requires deeper layout treatment. This article owns the reviewability of the roof basis before those decisions expand.

How should conflicting roof-model sources be handled?

Conflicting roof-model sources should remain visible until an owner selects or creates the controlling basis. Record each candidate source, date, purpose, difference, confidence, and affected geometry. Stop any release that depends on the unresolved field, while allowing narrower work only under limits. Never average dimensions, choose the sharpest image, or let the newest file win without confirming authority and relevance.

Start with the disputed element rather than the whole roof. A source conflict may affect one addition, height relationship, obstruction, or roof edge while the main footprint remains usable for a limited discussion. The release record should distinguish the held area from geometry supported by independent evidence.

Illustrative workflow example, not a surveyed project result: An aerial source shows a clean rear roof edge, while a newer customer photograph suggests an addition extending beyond it. The photograph does not expose enough geometry to model the addition confidently, and no current survey is available. The modeler keeps both records and labels the rear area unresolved.

The team does not stretch the aerial outline to approximate the photograph. It preserves the original source geometry, adds a neutral uncertainty envelope, and blocks final placement or another dependent release in that area. A survey or qualified site observation becomes the closure evidence. Preliminary discussion elsewhere on the roof may continue only if the release owner accepts that narrower use.

Use a conflict record:

Disputed element:
Candidate sources and dates:
Purpose and authority of each source:
Observed difference:
Current working representation:
Confidence and uncertainty envelope:
Decision blocked:
Work allowed to continue:
Owner authorized to resolve:
Evidence required for closure:
Outputs to revise after closure:

When the conflict closes, correct the controlling geometry first. Then regenerate or recheck layout, shading, analysis, bill of materials, proposal, electrical records, or other consumers affected by the change. Do not edit a downstream screenshot to resemble the new roof while its originating model remains stale.

Notify recipients who received the provisional representation when the corrected geometry changes their decision. The source ledger should retain the superseded basis, its allowed use, and the reason it changed. That history prevents a future reviewer from restoring the older edge because it appears in a familiar attachment.

Before release, give the packet to someone who did not build the model. Ask them to identify the controlling source for one plane, explain one uncertainty, locate the current orientation and scale basis, and state which downstream use is allowed. Do not coach them through the folder. Their difficulty reveals whether the packet transfers knowledge or merely archives files.

If the independent reader chooses a stale source, misses a prohibited use, or cannot find the closure owner, repair the index and labels before changing geometry. Reviewability is an interface property. The underlying work can be sound while the handoff still forces another designer to reconstruct it.

Use stop conditions instead of finishing by appearance

A model is ready for its stated review when required sources are attached, controlling geometry closes, scale and orientation are checked, sampled dimensions agree within the approved method, objects and zones carry status, and open conditions have owners. It is not ready because the roof “looks right.”

Define stop conditions before work begins. A parcel mismatch, missing scale basis, unresolved major plane, conflicting current survey, or unknown object controlling most of the available placement area may block the intended release. The same condition may allow a narrower preliminary use if clearly qualified.

When the model cannot progress, return one precise evidence request. State the affected roof area, the missing observation or document, why it controls the next decision, who can supply it, and what work can continue meanwhile.

This approach protects speed by preventing speculative detail. A modeler stops at the evidence boundary rather than spending another hour polishing geometry that a survey may replace.

Control changes after the first layout

Once modules appear, roof changes become project changes. A corrected edge can alter module fit, string membership, shade results, BOM, production model, proposal, and electrical record. The roof-model change log should identify affected outputs.

Use change categories: source update, geometry correction, object update, governed-zone update, layout-driven clarification, and field finding. State whether the change supersedes an assumption or adds new evidence.

Do not overwrite the released model. Preserve the prior version and the audience that used it. If a customer saw a layout based on provisional geometry, the project record should show whether a corrected view was supplied.

Complex solar roof design checklist covers broader array decisions around complicated roofs. Keep this model checklist focused on making the roof basis reviewable before placement decisions multiply.

Solar Designing describes SurgePV’s relevant approved product scope. Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Review the failure modes that polished views conceal

Some roof-model defects look like minor graphics until modules are placed. Review them deliberately before release.

A scale defect keeps proportions believable while changing every distance. Test scale with more than one independent controlling dimension when the approved method and available evidence permit it. If those checks disagree, investigate image distortion, source dates, endpoints, and coordinate handling rather than averaging the discrepancy.

An orientation defect rotates an otherwise accurate roof. It can change plane azimuth, simulated sun relationships, and the way a designer interprets access or routing. Compare orientation with stable site features and the source’s coordinate convention. Do not “correct” north until the team knows which north the model currently represents.

A topology defect occurs when edges do not create the intended planes. Tiny gaps, overlaps, doubled vertices, or twisted surfaces may be hard to see from overhead. Inspect wireframe or edge views, plane normals where the tool exposes them, and oblique sections. Confirm that valleys drain into the expected geometry and ridges join the correct faces.

An elevation defect allows the footprint to match while roof heights do not. Shadows, parapet relationships, dormers, and step roofs can then behave incorrectly. Compare independent vertical evidence and inspect silhouettes from source-matched viewpoints. Mark any height inferred from perspective as provisional.

An object-classification defect gives uncertainty a confident name. A dark patch becomes a vent; a small rooftop item becomes an HVAC unit; a tree-covered feature disappears. Use neutral object labels and conservative envelopes until evidence supports identity and dimension. The design consequence matters more than a neat asset icon.

A freshness defect appears when each source is individually plausible but the site changed between capture dates. Additions, removed trees, replaced equipment, reroofing, and neighboring construction can all separate the model from present conditions. Put capture dates beside the elements they support and identify which parts need current confirmation.

A presentation defect hides uncertainty at export. Confidence colors disappear in grayscale, a note is clipped, or the PDF omits the source ledger. Inspect the actual deliverable that the next role will receive, not only the interactive modeler’s view.

For every defect, record the affected decision. A small edge error may be immaterial to early massing but decisive in a narrow module row. A missing distant object may be irrelevant to fit and important to shade. Severity belongs to the intended use, not to how dramatic the model looks.

Finish this pass by asking what could make the current model wrong tomorrow. A planned survey, expected roof work, pending site photographs, or a newer imagery order should become a refresh trigger. The model remains reviewable only if another person can see when its evidence expires.

Keep a defect log separate from the visual markup. The log should identify the element, source, suspected failure mode, diagnostic check, disposition, reviewer, and release effect. Visual arrows help locate an issue; they do not preserve the decision. Close a defect only after the model, its source record, and every affected export agree. If the team accepts a provisional condition, retain its confirmation trigger and downstream restriction rather than erasing the finding.

That discipline also gives the next revision a trustworthy starting point.

Frequently Asked Questions

What makes a solar roof model reviewable?

A reviewable model identifies its project purpose, source material, date, coordinate and orientation basis, modeled geometry, assumption status, validation checks, and unresolved conditions. Another designer should be able to select a roof edge, plane, height, or obstruction and trace it to evidence without asking the modeler to reconstruct the work verbally.

Can imagery replace a solar site survey?

Imagery can support screening and preliminary modeling when its age, resolution, viewpoint, and limits suit the intended decision. It does not verify every dimension, material, structural condition, obstruction, electrical detail, access issue, or change at the site. Label the model’s allowed use and required field confirmations clearly.

How many roof dimensions should a reviewer check?

Use a risk-based sample rather than a universal number. Check controlling spans, irregular boundaries, plane transitions, narrow placement areas, and dimensions that affect setbacks, access, or module fit. Increase the sample when sources conflict, image quality is weak, geometry is complex, or the model supports a higher-consequence release.

Should every small roof object appear in the model?

Model objects that can change the intended layout, shade analysis, access, routing, construction discussion, or customer interpretation at the chosen level of detail. Record uncertain objects rather than inventing dimensions. Tiny visual texture need not become geometry unless it affects the decision the model is meant to support.

Does a clean 3D roof model prove a solar design will fit?

No. A clean model can make geometry and assumptions easier to inspect, but fit depends on source accuracy, site changes, equipment, setbacks, access, structural and electrical conditions, and review. Treat preliminary placement as a scenario until the evidence and responsible professionals support the release purpose.

The review trail is part of the model

Reviewable roof geometry includes the reasons behind it. A plane without a source, an object without confidence, or a setback without jurisdiction is only a shape. Another designer may be able to see it but cannot responsibly reuse it.

Build enough geometry for the next decision, expose every important assumption, and stop when evidence stops. That is how “fast” becomes a workflow property rather than a marketing claim about modeling time.

Review a roof model in a guided SurgePV demo

Bring a representative roof and discuss how 3D modeling, layout, shading, analysis, and downstream records can fit your review process.

Book a guided demo

Sources

Primary research and reference material used for this desk-research article.

Where this fits

This article is part of SurgePV's Solar Business & Operations hub, which works through the topic from first principles to the decisions a project team actually has to make.

About the Contributors

Author
Akash Hirpara
Akash Hirpara

Co-Founder · SurgePV

Akash Hirpara is identified by SurgePV as a company co-founder. His SurgePV author page lists only role information that can be tied to the public profile below; education, certifications, project totals, financial results, speaking engagements, and media appearances are not asserted without retained evidence.

Editor
Rainer Neumann
Rainer Neumann

Editorial contributor · SurgePV

Rainer Neumann is credited as an editorial contributor on SurgePV content. This profile does not assert engineering credentials, project totals, software-testing experience, education, speaking engagements, or media citations because independent verification evidence is not retained in the publication record.

Get Solar Design Tips in Your Inbox

Join 2,000+ solar professionals. One email per week - no spam.

No spam · Unsubscribe anytime

Book Free Demo

Choose which optional technologies SurgePV may use. Essential storage remains active for security and requested features.