Solar Production Estimate Assumption Register: How to Make Forecasts Reviewable

A solar production estimate is credible when a reviewer can trace its material inputs and understand what would cause the result to change. The number at the end of a model may be useful for a proposal, investment discussion, or design comparison, but it is never the whole forecast. The useful question is not only “What does the model produce?” It is “What did the model assume, what evidence supports those assumptions, and which of them remain conditional?”

This article is desk research for installers and EPCs. It does not provide an energy yield guarantee, investment advice, a bankability opinion, or a substitute for project-specific engineering, metering, weather analysis, tariff review, or legal terms. Different tools, datasets, loss methods, and project types can produce different results from the same site. The process below makes those differences easier to discuss before a customer or decision-maker mistakes a scenario for a promise.

Why a Single Annual-kWh Figure Is Not Enough

Production estimates travel fast inside a solar business. A designer uses one to compare layouts. A salesperson uses it to explain a proposal. A finance conversation may translate it into savings, revenue, payback, or risk. A project manager may later use it to spot whether an installed configuration differs from what was described. Each use can be reasonable, but only when the estimate carries its assumptions with it.

The NREL PVWatts calculator describes itself as a tool for estimating the energy production of grid-connected photovoltaic systems. It is a valuable public reference and a useful way to understand the categories of model inputs. It does not validate a particular roof, system layout, tariff, or customer claim. A modeled result remains conditional on the site and assumptions entered.

An assumption register prevents a common communication failure: a preliminary number is copied into a proposal, then the project changes while the explanatory basis disappears. The number may stay similar enough to avoid immediate attention, but a changed orientation, shading treatment, inverter, module count, loss input, consumption pattern, or operating plan can alter what the original result meant.

Define the Decision Before Choosing the Model Detail

The level of analysis should fit the decision. Early sales screening may compare broad options using limited evidence. A technical design review needs a more controlled set of inputs. A financial decision may require its own treatment of degradation, price escalation, curtailment, availability, consumption, export treatment, and uncertainty. Calling all of these “the estimate” hides meaningful differences.

Write a purpose statement before modeling. Examples: “Compare two preliminary roof-layout options using currently available site information,” “support a customer-facing annual-energy scenario,” or “review the consequence of a confirmed module-count change.” The statement should say what the estimate is for and what it is not for. It prevents a screening output from being reused as a construction or investment commitment without further review.

The NREL solar resource maps and data help explain why resource data is location-specific and dataset-based. They do not replace a project team’s decision about which data source, time period, spatial resolution, or loss treatment is suitable for a particular use.

Build the Register Around Inputs That Change Decisions

An assumption register should not become a transcription of every software field. Concentrate on inputs that can change the result or change the way someone should rely on it. Start with categories, then include only meaningful project entries.

Each row needs a status. A three-part status is often enough: supported, planning assumption, or required before a later release. “Supported” means a named source exists and is suitable for the current decision, not that the project is free from uncertainty. “Planning assumption” means the team used a value to explore a scenario. “Required” means the estimate should not be relied on for the stated later use until the matter is resolved.

Separate Resource Data, Site Evidence, and Model Judgment

These categories are related but different. Resource data might come from a named public dataset. Site evidence may include survey notes, imagery, drawings, photographs, or measured conditions. Model judgment includes choices about losses, shading treatment, configuration, and the intended scenario. Blending them into a generic “data source” field makes it harder to review the outcome.

For example, an address may be supported by customer documentation, orientation may be based on a preliminary roof model, and vegetation may be an unverified observation from imagery. A thoughtful register says so. It does not claim that all three are equally confirmed merely because they were entered into the same software project.

This is also where Shadow Analysis is relevant. A shading workflow can help teams model and communicate shade conditions, but it cannot establish that a modeled roof surface, neighboring feature, or future vegetation condition represents site reality without appropriate project evidence and review.

Retain the Exact Run, Not Just the Software Name

A register row should point to a reproducible model state. Keep the input export or controlled project revision, software/model version, weather-file identity, loss treatment, run timestamp, output field and release identifier together. A screenshot alone rarely captures that basis.

The PVWatts V8 API documentation distinguishes request inputs, service version, calculation-library information, weather-station/file information and outputs. It also separates annual AC energy in kWh from hourly AC power in watts. These are concrete examples of identifiers and units to retain; they do not verify another software platform’s capabilities.

A typical-year weather file is a modeling basis rather than a prediction of the next calendar year’s weather. If the method or source changes, preserve the earlier run so the reviewer can distinguish a software update from a design change.

Give Each Assumption an Owner and a Trigger

Registers become useful when they influence action. For every material open item, name who can resolve it and what event will cause the estimate to be reviewed. An owner can be a role rather than an individual where the organization works that way, but it must be specific enough to act: site survey lead, design owner, customer contact, procurement lead, electrical reviewer, or commercial lead.

Triggers are equally important. A new module model, confirmed tree condition, revised roof geometry, storage addition, changed export arrangement, updated interval data, or changed operating schedule may require a rerun. Do not state that any one of these always changes energy by a fixed percentage. The impact depends on the project. The trigger is a request to reassess, not a pre-decided conclusion.

Copy-ready material-assumption row

Keep the row with the detailed project record. Use the eight buyer-facing proof points to decide what the customer should see; that presentation does not replace the internal register. The sales trust checklist belongs to the release conversation rather than the definition of a model input.

Record Loss Stages Before Comparing Revisions

SAM’s photovoltaic loss documentation identifies several mechanisms and model stages. An input labeled “loss” should say what it reduces and whether another field already includes the same effect. Do not apply an additional percentage merely because a second report lists it.

For an independent arithmetic illustration, assume 10,000 kWh at an inverter-AC boundary and a hypothetical method that applies a 2% wiring reduction followed by a 3% availability reduction. Its final quantity is 10,000 × 0.98 × 0.97 = 9,506 kWh, not 9,500 kWh from simply adding the percentages. The stages and order are assumptions of this example, not instructions for a particular tool.

If the wiring assumption changes to 1% while every other input stays fixed, the successor is 10,000 × 0.99 × 0.97 = 9,603 kWh. The change is 97 kWh, about 1.02% of the previous output. Record the input change, run and affected released artifact. A one-percentage-point input change is not automatically a one-percent energy change.

Show the Difference Between Energy, Savings, and Outcome

Annual energy output, bill savings, revenue, payback, and return metrics are not interchangeable. Energy is one modeled output. Financial outcomes also depend on consumption alignment, tariff structure, export treatment, charges, financing, incentives where applicable, operating costs, and other assumptions. An assumption register should show when an article, proposal, or internal model moves from an energy scenario into a financial scenario.

Avoid attaching an energy estimate to a promise such as “your bill will fall by this amount.” A responsible statement is more specific: “This is a modeled annual energy scenario for the listed design and inputs; financial results require the tariff, consumption, export, and commercial assumptions stated in the proposal.” That sentence does not weaken the customer conversation. It tells the reader what evidence would improve the answer.

Project-specific financial modeling requires current local data and terms; a technology reference cannot confirm an individual customer’s tariff treatment or future savings.

Use Scenario Labels Instead of Hiding Uncertainty in Footnotes

When the purpose allows it, present defined scenarios rather than implying that one number represents every possible future. A design comparison can show “current preliminary layout” and “layout after survey confirmation.” A commercial review may compare stated operating profiles. The key is that each scenario names what changed and what stayed fixed.

Do not label an arbitrary high/base/low comparison P50, P75 or P90. Retain the uncertainty method, weather basis, parameter distributions, modeled period and assumptions. The laboratory report Quantifying Uncertainty in PV Energy Estimates discusses probabilistic energy estimates and their uncertainties. A sensitivity case that changes one input is not automatically an exceedance-probability estimate. The PV generation and financial modeling is the appropriate SurgePV destination for teams evaluating connected simulation and financial workflows, while project-specific assumptions still need qualified review.

Review the Register at Handoffs

The register should not be created once and forgotten. Review it at moments when people tend to copy outputs forward: before a proposal is issued, when a design changes, before a customer signs a scope, before procurement locks equipment, and before a construction or financial release uses the estimate. The review can be short when no material input has changed. It should be deeper when a trigger appears.

Keep the review history factual. “Rev 2 issued after confirmed roof survey; orientation and shading inputs updated” is useful. “Numbers now accurate” is not. All models have boundaries, and accuracy claims require evidence beyond an internal status note.

Questions for a Proposal Reviewer

1. What configuration, resource input, and site treatment produced this estimate?
2. Which values are sourced from current project evidence, and which remain assumptions?
3. Does the customer-facing language describe a modeled scenario rather than a guaranteed result?
4. Did an equipment, site, shading, consumption, tariff, or operating input change after the estimate was run?
5. Which owner is responsible for each condition that must be resolved before the next release?

Close a Changed Assumption Without Erasing Its History

Retain the original value and evidence, the accepted replacement, reason, reviewer and successor run. Mark affected outputs under review until the responsible person determines whether the change requires recalculation. After a rerun, identify and replace the proposal chart or financial scenario that used the earlier output. A corrected register with stale released copies has not completed change control.

Practical Next Steps

1. Add a source, date, status, owner, and rerun trigger to every material model input.
2. Label customer-facing results as modeled scenarios and state their design and data boundary.
3. Recheck the register whenever the site, system, shading, equipment, consumption, tariff, or operating assumptions change.

Frequently Asked Questions

What is an assumption register for a solar production estimate?

It is a controlled list of the inputs and judgments behind a forecast. Each material entry should state the value or method, source, date, status, owner, and the decision or release it affects. It turns a single output number into a reviewable project record.

Does an energy-model estimate guarantee solar output?

No. Production depends on resource data, weather variation, equipment, design, site conditions, shading, losses, availability, operation, and other assumptions. Present the result as a modeled scenario with stated inputs and boundaries, not as a guarantee of energy or financial outcome.

When should a team rerun a solar production estimate?

Rerun it when a material input changes or when the estimate is being used for a more consequential decision. Common triggers include a changed layout, module or inverter selection, verified survey finding, revised shading treatment, updated consumption information, changed tariff assumptions, storage addition, or a different operating plan.