Quick Answer
A solar project evidence register is a short list of the documents, observations, and decisions that support a project output. For each item, record its source, date, status, intended use, owner, and what would invalidate it. This prevents assumptions from being mistaken for verified site facts.
Solar teams do not usually lack information; they lack a reliable way to say what that information proves. A project folder may contain a bill, a roof photograph, a PDF drawing, a customer email, and a utility link. Without a register, the next person can easily treat any one of those items as confirmed technical evidence. The result is often a proposal based on a reasonable assumption that later travels too far into purchasing, scheduling, or field work.
An evidence register fixes the handoff problem before it becomes a technical problem. It gives every material project input a source, a date, an allowed use, and an owner for the next check. This desk-research guide is for installers and EPCs. It does not replace site inspection, code review, engineering judgment, utility requirements, manufacturer instructions, contractual review, or project-specific safety planning.
Direct Answer
For every decision-changing project input, record what the item is, who supplied it, when it was created, what decision it can support, whether it is confirmed or assumed, and what must happen before a higher-stakes release. The register should make an uncertain input visible instead of making it disappear inside a polished proposal.
The Difference Between a File List and an Evidence Register
A file list answers “what is in this folder?” An evidence register answers “what can this item support?” Those are different questions. A drawing received from a customer may be useful for a screening layout, but its revision and origin may not support a construction decision. A bill may document historic consumption for a stated period, but it does not prove future operating patterns. A photo may confirm that an object was visible at a time, while leaving dimensions, access, or underlying construction unknown.
This distinction becomes especially important when project work passes through sales, design, operations, procurement, and installation. Each role needs information at a different level of confidence. The register enables the team to be precise without pretending that early information is worthless.
NREL’s PVWatts documentation is an instructive public example. A modeled energy result depends on stated inputs and model assumptions. It is meaningful only within those conditions. A project evidence register applies the same discipline to project work: identify the input, identify its origin, and avoid extending its meaning beyond what it supports.
Start With the Decision the Evidence Must Support
Do not create an evidence register as a generic archive. Begin with a decision. Typical examples include:
- whether an opportunity is suitable for a preliminary solar scenario;
- whether a proposal can state a selected configuration and commercial scope;
- whether a material list can move to procurement;
- whether a permit or interconnection package has the required source documents;
- whether a field team has the information needed for the defined release.
The same document may have a different status for each decision. A roof image can be enough to start a remote screening exercise, but not enough to verify roof condition, attachment details, working access, or a final layout. Write the allowed use in the register. It keeps a valid early input from becoming an invalid late input.
The Seven Fields Every Register Needs
The register can be a table, database record, or controlled project form. It should be quick to update and visible at handoff. These seven fields make it useful.
| Field | Example entry | Why it matters |
|---|---|---|
| Evidence item | Electricity bill, roof photo set, drawing, utility letter | Gives the team a shared object to discuss |
| Source and date | Customer supplied; billing period stated on document | Shows where the information came from and how current it is |
| Relevant decision | Preliminary production scenario | Stops the item being used for an unrelated release |
| Status | Confirmed for stated use, planning assumption, or required before release | Makes uncertainty visible |
| Material impact | Could change load basis and financial scenario | Helps prioritize follow-up |
| Owner | Sales coordinator, surveyor, designer, or named reviewer | Turns a gap into assigned work |
| Next action | Request 12 months of bills before final commercial scenario | Gives the project a path forward |
Avoid one vague status such as “received.” Received says nothing about quality or relevance. Likewise, do not use “verified” without naming the verification and its purpose. A surveyor’s dated observation may verify a feature for a stated layout review. It does not automatically verify every structural, electrical, regulatory, or access question connected to the site.
Classify Inputs by Evidence Strength
Teams can use different labels, but three categories generally cover the practical need.
Confirmed for the Stated Use
Use this label when an identifiable source is current enough and appropriate enough for the specific decision. A current utility bill may be confirmed as the customer’s supplied record for a billing period. A dated survey observation may be confirmed for the feature observed. An approved project decision can be confirmed as an instruction within its revision.
The wording matters: confirmed for the stated use. It avoids a common error where a true fact is used to support a different conclusion. A known annual consumption figure does not tell a team when the facility consumes power. A confirmed module data sheet does not determine whether that module is available for the project. A marked roof dimension does not answer every field condition.
Planning Assumption
This label is appropriate when the team needs a scenario to have a productive conversation before all evidence exists. It may include a roof dimension estimated from imagery, a preliminary tariff treatment, a customer-stated operating pattern, or a selected equipment category. The label is not an admission of poor work. It signals that the output is scenario-based and names what could change it.
The requirement is visibility. Put material assumptions in the proposal basis and in the handoff record, not only in a private designer note. A customer deserves to understand which condition will be checked before final scope is established. The next internal role needs the same information.
Required Before Release
Use this status for a missing or unresolved item that prevents a named decision. Examples may include confirmation needed before final electrical selection, site information required before field release, or current authority guidance needed before an application. Assign a person and date. “To be confirmed” does not tell anyone who will resolve the issue or why it matters.
Record Provenance, Not Just Content
Provenance is the route by which information reached the project. It is often more valuable than the content itself. A photo without a date, source, or project identifier may still be helpful, but its limitations should be visible. A utility webpage can be a useful reference but may not be the current project-specific instruction. A vendor conversation can indicate availability but needs a durable record before it controls procurement.
For each material item, record:
- Who supplied or created it?
- When was it created or observed?
- Which site, account, drawing revision, or project does it identify?
- Has anything changed since it was created?
- Which decision is it suitable to support?
These questions are fast when asked at intake and expensive when asked after a proposal changes. The U.S. Department of Energy’s Solar Energy Technologies Office provides broad resources on solar deployment. It is not evidence for a particular project condition. Keeping public reference material separate from project evidence helps a team avoid accidental overstatement.
Keep Solar Inputs, Models, and Proposals Connected
Explore how SurgePV supports teams moving from project inputs into solar design, Shadow Analysis, generation and financial modeling, and customer-facing proposals while review decisions remain with your team.
Book a DemoBring an active evidence or handoff question to a live walkthrough.
Build the Register at Intake, Then Maintain It at Change Points
The best time to create an evidence record is when an item enters the project. Waiting for a design review invites memory-based reconstruction. A simple intake process can capture the source, date, and intended use of bills, drawings, photographs, customer statements, and utility communications.
Update the record whenever a meaningful change occurs. Common change points include a site survey, new consumption information, a design revision, equipment substitution, customer scope change, utility correspondence, or authority instruction. The update does not need to repeat the whole register. It should show what changed, what the current item replaces, and which output now needs review.
This is also where Solar Designing can be relevant. A connected workflow can reduce the friction of locating inputs and current outputs. It cannot determine whether a photograph is current, whether a local rule applies, or whether a technical decision requires a qualified reviewer. Those remain project responsibilities.
Use the Register to Improve Customer Communication
Customers do not need an internal data-management lecture. They do need a clear explanation when additional evidence is required. The register helps a team phrase that request precisely: “To refine this proposal, please provide the most recent bills for the relevant period,” or “Before final configuration, we need to confirm the electrical information at the site.”
This is more credible than offering a firm number and later reclassifying it as preliminary. It also reduces vague requests. Instead of asking for “more information,” explain which document or observation affects the next decision and what will happen once it is received.
Never use the register to imply a guarantee. A complete-looking folder cannot guarantee a production outcome, authority approval, schedule, site suitability, or final project cost. The register merely makes the evidence boundary inspectable and gives the team a controlled way to move from one decision stage to the next.
Audit Returned Work for Missing Evidence Patterns
When a project is returned because an input is missing, unreliable, or inconsistent, log the reason. Examples include outdated bills, unidentifiable images, drawings without a revision, differing site addresses, missing operating schedules, or a customer expectation not reflected in the proposal. Review the patterns periodically.
The appropriate fix is often upstream. Add an example to an evidence request, ask one better intake question, create a mandatory field for a source date, or make an assumption visible in the proposal. Do not turn a handful of internal returns into a universal industry statistic. The practical purpose is to make the next project more reliable.
Practical Next Steps
- Add the seven evidence fields to project intake and handoff records.
- Label material inputs by what decision they support, not merely by whether they were received.
- Assign an owner and release boundary to every evidence gap that can change scope or output.
Ready to Make Solar Project Evidence Easier to Trace?
Book a free SurgePV demo to explore connected Solar Designing, Shadow Analysis, generation and financial modeling, and Solar Proposals.
Book a Free DemoFrequently Asked Questions
What is a solar project evidence register?
It is a controlled list of project information that records source, date, permitted use, status, impact, owner, and next action. It helps each role see which statements are supported and which conditions still require work.
Which documents should be in a solar evidence register?
Common entries include customer bills and interval data, drawings, photographs, survey observations, utility correspondence, equipment documents, authority guidance, and approved project decisions. The exact list depends on the intended release.
Does an evidence register replace a site survey?
No. It clarifies what the team knows and what it still needs to verify. A site survey, qualified review, or authority confirmation remains necessary when the relevant project decision requires it.
