Solar Design Basis Record: How Installers Keep Assumptions Reviewable

A solar design basis record makes the reasoning behind a layout visible before someone has to reconstruct it from an inbox. It is not a long report and it is not an engineering certificate. It is the short, controlled record that says what the team knew, what it assumed, what it selected, and what must still be checked before another decision is made.

For an installer or EPC, that distinction is practical. A first proposal may use an address, a bill, imagery, a customer objective, and equipment assumptions. A later designer, procurement coordinator, or field lead needs to know which of those inputs have changed. Without a design basis, a layout can look authoritative while its reasoning is scattered across calls, messages, spreadsheets, and revisions.

Start With the Decision, Not a Blank Template

A basis record is useful only when it has a purpose. “Solar project” is too broad. “Support a commercial proposal for a roof-mounted system” is better. “Issue a purchasing list for a selected configuration” is different again. The decision tells readers how much evidence they should expect and stops an early scenario from quietly becoming a construction instruction.

The U.S. Department of Energy describes solar as a system whose deployment involves technology, market, and local implementation considerations. Its Solar Energy Technologies Office resources are useful context, but they do not verify a particular roof, service, tariff, or permitting path. A project record needs the project’s actual evidence.

Write the first line as a release statement: “This revision supports a customer discussion of two preliminary options,” or “This revision is prepared for technical review of the stated array configuration.” Then say what it cannot support. A proposal-basis record, for example, is not automatically a permit set, final structural assessment, procurement authorization, or field instruction.

That small discipline changes the conversation. Instead of debating whether a document is “final,” people can ask whether it is fit for a named decision. It also gives a sales representative a clear way to explain uncertainty without making the proposal vague.

Capture Inputs With a Source and a Date

The core of the record is not a list of software fields. It is traceability. For every material input, note where it came from, when it was received, and what it is being used to support. A customer’s annual bill may be suitable for an initial consumption discussion, but it may not explain a future load change. Satellite imagery may be useful for a screening layout but cannot confirm every roof feature or access condition.

Use a simple input table:

Do not call a field “confirmed” merely because it was copied into a model. Confirmed means the source is identifiable and adequate for the stated use. A bill can confirm billed usage for the period shown. It cannot prove that next year’s consumption will match. A photograph can show a visible obstruction. It may not answer a structural question. Precise language keeps a team from giving an input more authority than its source supports.

Separate Assumptions From Decisions

Teams often mix the two. “Use 450 W modules” might be a decision for a particular commercial option; “modules remain available at the quoted price” is an assumption. “No substantial shading found” may be a modeled conclusion based on available imagery; “field verification required” is an open condition. The record should let a reader distinguish these categories in seconds.

An assumption should answer three questions: what is assumed, why does it matter, and what will verify or replace it? For example: “The financial scenario uses the tariff shown on the supplied bill; the customer will confirm the current tariff before contract pricing.” The sentence is more useful than a generic disclaimer because it names the evidence and the next action.

Decisions need their own rationale. If the team chose one system size over another, record the customer objective, relevant consumption basis, physical constraint, or commercial comparison that informed that choice. That does not transform a selection into a guarantee. It makes later revisions understandable. When a buyer asks why a smaller option was included, or procurement asks why a particular inverter class was selected, the response should not depend on one person remembering a call.

Treat Model Results as Outputs With Conditions

Production and financial figures are especially likely to outlive the assumptions that produced them. NREL describes PVWatts as a calculator that estimates energy production and value for grid-connected PV. The word “estimate” matters. Any project-specific scenario depends on its weather data, geometry, equipment inputs, losses, shading treatment, consumption basis, and financial assumptions.

The basis record should therefore name the version or source of the model, not reproduce every calculation. Capture the orientation and array concept, weather or resource basis where relevant, loss and shading treatment, energy-consumption source, tariff assumption, and any storage or export treatment. If an item is unknown, say so. Hiding an unknown does not make the model stronger; it only makes a later explanation harder.

This is where a connected Generation & Financial Tool can support a team by keeping modeled generation and financial scenarios close to the design record. It does not eliminate the need to review inputs, interpret results appropriately, or verify local utility and contract conditions.

Make Exclusions Useful Rather Than Defensive

An exclusion is useful when it directs work. “All items subject to verification” is broad enough to be ignored. “Service capacity has not been verified and may change inverter selection; technical survey owns confirmation before electrical release” is actionable. The distinction matters to the customer and to the team.

Create a short change-trigger list. Include only conditions that could materially change scope, price, system configuration, modeled result, schedule, safety planning, or compliance. Common examples include roof condition, roof access, electrical service characteristics, equipment availability, site-obstruction findings, ownership authority, utility requirements, and a changed consumption profile. The list will differ by project; do not paste a fixed catalogue into every record.

Each trigger needs an owner and a decision point. A field survey may own roof measurements. A sales owner may request an updated bill. A qualified reviewer may own an issue that falls outside ordinary design work. The goal is not to distribute blame. It is to make sure the gap becomes a task before it becomes a surprise.

Link the Basis to the Revision, Not the Person

Projects move between people. A reliable record must survive that movement. Give the basis record a revision identifier and connect it to the relevant layout, proposal, and bill of materials references. When something changes, create a new revision or a clear amendment. Do not silently replace an old assumption and leave customer-facing numbers from the earlier version in circulation.

The change note can be short: “Revision B replaces preliminary roof dimensions with survey measurements; module count and annual scenario updated; customer proposal v1 superseded.” This tells sales, design, and operations what changed without forcing them to compare every page. It also supports an honest customer conversation: the revised output exists because new evidence arrived, not because the team is changing its story without explanation.

Avoid ownership by private memory. A reviewer can be named, but the record should contain the evidence and decision itself. If the person who prepared the first layout is unavailable, the next colleague should be able to determine the intended scope, evidence status, and open actions from the project file.

Use a Different Basis Depth at Each Stage

The record should grow with the consequence of the decision. At qualification, it may be a single page identifying customer goals, available evidence, major unknowns, and the next request. At proposal, it should explain the configuration, commercial and modeling assumptions, exclusions, and expected verification path. At a technical or procurement release, it needs the approved configuration, controlled revisions, relevant checks, and unresolved conditions that prevent release.

More detail is not automatically better. A 30-page attachment that no one reads is weaker than a one-page record with accurate sources and clear owners. Use links to controlled evidence rather than duplicating every photograph or document. The record is an index of reasoning, not a substitute for the source material.

The appropriate review also changes. Sales can confirm whether a proposal reflects the customer discussion. Design can confirm internal consistency of the configuration. Issues involving code, structural conditions, utility requirements, or safety need the review appropriate to the site and jurisdiction. A basis record documents the boundary; it does not allow a commercial team to perform work outside its remit.

Run a Pre-Send Check

Before a proposal or design output leaves the team, ask five questions:

1. Which decision is this version intended to support?
2. What evidence is current enough for that decision, and where did it come from?
3. Which assumptions could materially change the output?
4. What has changed since the prior shared revision?
5. Who owns each open condition and when must it be resolved?

If the answers are missing, pause long enough to write them down. That does not require a meeting. It may require one message to the customer, a request for a document, or a technical review. The small pause is often less costly than correcting a persuasive but poorly grounded proposal later.

How to Explain the Record to a Customer

Customers do not need internal jargon. They do need a plain statement of what they are reviewing. Say: “This option is based on the electricity information and site details available today. The attached assumptions list shows what we will verify before final release.” Then point to the two or three conditions most likely to matter.

That is not a retreat from a recommendation. It is a recommendation with an honest basis. It tells the buyer what information can make the next decision more confident and reduces the chance that a final change feels arbitrary. Teams can use Solar Proposals to present the customer-facing story, while retaining the project record that explains how the story was constructed.

A Compact Basis Record Template

Use these headings in a project system or controlled document:

• intended decision and permitted use;
• project revision and date;
• customer objective and selected configuration;
• material inputs with source, date, and status;
• model and financial scenario assumptions;
• exclusions and change triggers;
• unresolved conditions, owner, and required-by stage;
• reviewer or release route; and
• link to the customer-facing proposal version.

The template should prompt thinking, not become a form-filling exercise. If a field is irrelevant, mark it not applicable and move on. If an unusual condition could change the project, add it rather than forcing it into an unrelated box.

Frequently Asked Questions

What is a solar design basis record?

It is a dated project record explaining the intended decision, inputs, assumptions, selected configuration, exclusions, unresolved conditions, and revision behind a solar design. It helps a later reader understand the basis of the output without treating it as a guarantee.

Who should prepare the record?

The person or role preparing the relevant output can begin it, but the content should draw on sales, design, field, technical, and operations input where each owns a material condition. The release route should match the decision being made.

Does the record replace a site survey?

No. It makes survey needs visible and records what evidence was available before the survey. Field verification, qualified review, local requirements, and manufacturer instructions remain separate responsibilities.

When should the record be revised?

Revise it when a material input, selected configuration, model assumption, scope condition, or intended decision changes. Mark the former customer-facing version as superseded where appropriate.