Solar Design Assumptions Register: How to Stop Provisional Inputs Becoming Commitments

Every solar project starts with incomplete information. The operational risk begins when an early estimate is later read as a confirmed fact. An assumptions register gives installers and EPC teams a place to keep provisional inputs visible while work moves forward. It is not a long risk log and it is not an excuse to avoid verification. It is a practical answer to a common handoff problem: someone needs a layout, a financial scenario, or a customer conversation before every project condition can be known.

This guide is desk research for solar professionals. It does not provide a design, engineering determination, performance guarantee, price, schedule, utility outcome, or permitting advice for a specific site. A solar system’s actual scope depends on local requirements, field conditions, equipment documentation, project contracts, and the review of the relevant qualified people.

Why an Assumptions Register Is Better Than “TBC”

“To be confirmed” is a useful warning but a poor control. It does not say what is unknown, why it matters, who will find the answer, or whether the team may safely release the current output. An assumptions register adds those missing decisions without asking the whole organization to adopt a large governance system.

Consider a preliminary rooftop layout built from address information and imagery. The team may have a reasonable working roof area, orientation, and obstruction view. It may not know whether an upcoming re-roof is planned, whether equipment access is practical, or whether field-observed conditions will change the usable area. A design can still help a customer discuss options, provided its limits are clear. It cannot silently become a construction instruction.

The same principle applies to energy and financial estimates. NREL’s PVWatts calculator describes an estimation tool that uses user inputs and default assumptions. It is valuable for scenario analysis, but it does not validate a project’s tariff, load profile, roof condition, interconnection result, or savings outcome. The team should retain the particular inputs used and state which ones are supplied, modeled, or pending confirmation.

The difference is not bureaucratic wording. The second column tells the next person how to act.

Decide What Belongs in the Register

Not every small uncertainty belongs in a customer-facing project control. Track the inputs that could change a decision someone will make. A simple filter is useful: if this input changed tomorrow, could it affect scope, price, system size, yield, equipment selection, compliance route, schedule, or what the customer believes they are buying? If yes, capture it.

For most solar opportunities, the register will contain entries from five groups.

Site and Physical Conditions

Include roof geometry, obstruction observations, access, roof age or planned works, ground conditions, space for equipment, electrical-room access, and any field detail that affects the proposed approach. Do not describe desktop imagery as a survey. A project can use imagery for preliminary work; it should label the result accordingly.

Energy and Commercial Inputs

Track consumption records, interval data, tariff structures, operating hours, demand charges, export arrangements, escalation assumptions, incentives when applicable, and financing inputs. The source and time period matter. A bill summary may be enough for an initial conversation but inadequate for a detailed commercial analysis. A customer objective such as “reduce bills” is a goal, not a verified performance baseline.

Technical Configuration

Record equipment availability, module or inverter selection status, electrical service information, planned storage operation, layout constraints, and any rule that must be confirmed by the appropriate reviewer. An equipment model selected for a concept may later become unavailable or unsuitable for a field condition. The register should make that decision path visible rather than conceal it in a revised PDF.

Regulatory and Utility Inputs

Use the current authority and utility sources for the site rather than carrying a rule from a previous job. Keep the reference, date checked, and unresolved question. The U.S. Department of Energy’s Solar Energy Technologies Office offers broad deployment context; it is not a substitute for local code, interconnection, or authority instructions.

Customer and Contract Boundaries

Note what the customer has asked for, what has been excluded, which decisions they still need to make, and which timeline statements are conditional. This is where an assumptions register protects trust. A preliminary proposal can say what has been modeled and what must be confirmed. It should not promise a specific approval, saving, installation date, or technical result from incomplete evidence.

Use Five Fields That Make Each Entry Actionable

The register should be short enough for a salesperson, designer, project manager, and reviewer to use. These five fields are sufficient for many teams:

Add a sixth field only when it improves action: the deadline tied to a proposal, permit, procurement, or construction release. Resist assigning arbitrary numerical confidence scores. A 70% confidence label can create false precision. A plain explanation of source quality and release consequence is normally more useful.

An entry should be specific enough that a new team member can follow it without the original author in the room. For instance: “Annual consumption: customer supplied a twelve-month summary, not interval data; used only for high-level scenario; affects sizing and financial analysis; sales owner to request interval data before detailed commercial proposal.” That tells design what they may do now and what they must not imply.

Put the Register at the Right Moments in the Workflow

An assumptions register works when it follows actual decisions instead of becoming a document that is completed after the fact. Add or update it at four moments.

First, at intake, capture the customer’s objective and the information supplied. The team can decide whether to prepare a preliminary concept, request evidence, arrange a site visit, or route the opportunity for specialist review.

Second, at design, tie assumptions to the layout, model, and equipment selection. This helps a designer avoid treating a sales estimate as a technical instruction. It also lets the team compare a new field observation to the planning basis without reconstructing the whole opportunity.

Third, at proposal release, make sure the customer-facing explanation matches the record. Solar Proposals can help teams assemble customer-facing materials, but the responsible team still decides what a project is ready to claim. If roof dimensions, tariff data, or electrical conditions remain unconfirmed, communicate that boundary in direct language.

Fourth, at handoff, inspect which assumptions are still open and which have been resolved. A sale should not create a new memory test for operations. Pass the current evidence, the open questions, the intended release, and the next owner together.

Match the Review to the Consequence

An assumption is not automatically a flaw. It can be a responsible way to let an early-stage conversation proceed. The question is whether the proposed next output is proportionate to the evidence. An illustrative layout can carry more assumptions than a final technical release. A price discussion can use a defined allowance, while a contract or procurement instruction may require a more explicit scope decision.

Create named release points rather than one blanket rule. For example:

• Preliminary discussion: assumptions allowed when visible and not presented as guarantees.
• Detailed proposal: significant commercial and energy inputs reviewed; remaining conditions explained to the customer.
• Permit or technical issue: project-specific documentation and required professional review completed for the jurisdiction and scope.
• Procurement or construction handoff: selected equipment, quantities, revisions, and field dependencies reconciled by the responsible team.

These labels do not replace a contractor’s, engineer’s, authority’s, or utility’s requirements. They organize internal responsibility so a project does not cross a release boundary by accident.

Keep Models and Narrative in Agreement

Modeling has a particular risk because numerical outputs can look definitive. If a financial scenario uses a stated tariff, consumption profile, degradation rate, escalation rate, financing assumption, or export treatment, the written explanation should identify the material assumptions in understandable terms. Readers should not have to reverse-engineer a spreadsheet to discover that a central input was a placeholder.

This is where Generation & Financial Tool is relevant: connected software can help retain the path from design inputs to modeled financial outputs. It cannot determine whether a tariff will remain unchanged, whether a customer will consume electricity as assumed, or whether a utility will approve a proposed arrangement. Avoid calling a modeled outcome “guaranteed savings” or a project “approved” before the relevant decision has occurred.

The same discipline improves sales conversations. Instead of a vague disclaimer at the end, say: “This scenario uses the consumption and tariff information currently available. We will update it after we receive the latest records and confirm the site conditions.” That statement is more useful because it tells the customer what happens next.

Review Closed Assumptions After the Project Moves

Once an assumption is verified, record the outcome and whether it changed the project. This creates a modest learning loop. If a particular intake question frequently reveals a material difference, add it to the first conversation or site-visit brief. If a tariff source repeatedly arrives late, change the evidence request. If a specific roof feature routinely changes layout, make it a visible field check.

Do not use a few projects to claim a universal statistic about errors or savings. The purpose of this review is local process improvement. Record the project type, decision, evidence, and follow-up so the team can see a pattern without overstating what it proves.

A One-Page Assumptions Register Template

Use this starting format:

Give every line a closure event. “Confirmed from field survey on [date]” is a useful closure. “No longer relevant because customer changed scope” is also useful. Deleting the entry without a record removes the context the next reviewer may need.

Frequently Asked Questions

What is a solar design assumptions register?

It is a project record that identifies provisional inputs used in an estimate, layout, model, or proposal and assigns a source, owner, decision impact, and next verification action. Its role is to keep early-stage work honest and easy to hand off.

Which solar assumptions should be tracked?

Track assumptions that could materially change scope, price, design, yield, compliance, schedule, or customer expectations. Common examples include site conditions, consumption evidence, tariffs, equipment availability, electrical constraints, and authority or utility questions.

Does an assumptions register replace a site survey or engineering review?

No. It makes the limits of early information visible so the right survey, engineering, contractor, utility, or authority review can be requested before the relevant release. A solar design software workflow can preserve the record, but it cannot replace qualified judgment.