Solar Project Evidence Register: A Practical Record for Design and Proposal Decisions

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 makes the basis of a handoff inspectable. 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.

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.

NASA’s technical-data management guidance discusses managing data through its lifecycle. Apply the record principle by retaining source identity, revisions and access responsibility. This is a management analogy, not a solar standard or evidence that a private input is correct.

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.

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:

1. Who supplied or created it?
2. When was it created or observed?
3. Which site, account, drawing revision, or project does it identify?
4. Has anything changed since it was created?
5. Which decision is it suitable to support?

Capture those fields at intake and record any later change to their meaning. 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.

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. Evaluate the offered configuration for input references, current outputs and manual handoff dependencies. 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. Use the findings to revise intake requests and check whether the same gap recurs.

When two sources disagree, preserve both and open the conflicting-project-data checklist. A register indexes the evidence; conflict triage records how the disagreement was resolved or held.

Practical Next Steps

1. Add the seven evidence fields to project intake and handoff records.
2. Label material inputs by what decision they support, not merely by whether they were received.
3. Assign an owner and release boundary to every evidence gap that can change scope or output.

Frequently Asked Questions

What is a solar project evidence register?

It is a controlled list of the information that supports a solar project decision, including source, date, reliability status, intended use, owner, and unresolved gaps.

Which documents should be in a solar evidence register?

Typical entries include customer bills, interval data, drawings, photographs, survey observations, utility correspondence, equipment documents, authority instructions, and approved project decisions.

Does an evidence register replace a site survey?

No. It records what has and has not been established. A survey, qualified review, or authority confirmation remains necessary when the intended decision requires it.