Solar Design Decision Log: How Installers Keep Project Choices Traceable

A later reviewer may ask: “Why did we choose this configuration?” A layout has changed, equipment has been substituted, a proposal has been updated, or a site team has found an unexpected condition. The documents show what exists now, but not what evidence supported the earlier choice or which condition was meant to trigger another review.

A decision log provides that missing context. It is not a long meeting transcript and it is not a substitute for drawings, engineering, local requirements, contracts, or field verification. It is a compact record for material project choices: what was decided, why, what evidence was used, who owned the choice, and when the decision must be revisited.

Why Drawings Alone Do Not Explain a Project

Drawings and proposals are essential, but they describe an output more readily than the reasoning behind it. A plan may show a module layout without recording that it was an early scenario awaiting roof confirmation. A bill of materials may list an inverter without capturing that the selection was contingent on service information. A production estimate may show an annual value without explaining whether consumption, tariff treatment, shading assumptions, or export treatment changed after it was first modeled.

That lost reasoning creates avoidable work. A new designer has to reconstruct a decision from old emails. A project manager cannot tell whether an equipment change needs a customer conversation. Procurement may assume a configuration is fixed because it appears in a spreadsheet. The field team may receive an instruction that no longer reflects what sales discussed.

NASA’s configuration-management guidance discusses identification, change control and verification. It provides a limited process analogy for linking decisions to source records; it does not prescribe this solar log or approve a project. Retain the basis for choices that materially affect the next decision rather than trying to record every variable.

Decide What Is Material Enough to Log

Logging every mouse click creates noise. Logging only final approval creates gaps. The practical standard is consequence: record a choice when a later reader would need to know why it was made to proceed responsibly.

Routine changes within an already reviewed, low-consequence task can remain in ordinary revision history. A decision log is for the moments where the basis matters as much as the output.

Use a Six-Field Entry That Can Be Read Quickly

The entry should be usable during the next handoff. Keep it concise and link to source files rather than copying their contents.

For instance: “Use preliminary layout revision B for the customer discussion; basis: available imagery and customer-provided roof note; owner: design lead; affected record: proposal v2; reopen trigger: survey finding changes usable roof area or obstructions.” This statement does not claim the layout is final. It tells a reader why the team can use it now and what would invalidate that use.

The evidence field should retain its limits. A customer email supports a record of what the customer said. It does not establish structural suitability. A vendor statement may support a conversation about an equipment option. It does not supersede technical review or a controlled procurement confirmation. Describe sources faithfully rather than giving them more authority than they have.

Record Alternatives When They Explain the Choice

Not every decision needs a formal options analysis. When a choice could later look arbitrary, record the practical alternatives. A team might compare keeping a preliminary concept open, obtaining site data before proposal, or routing a condition for technical review. It might choose between a standard equipment configuration and a substitute that requires additional review.

The goal is not to prove that one option was universally best. Local requirements, availability, customer priorities, and site conditions vary. The goal is to document why the selected option fit the information available at that stage. That distinction keeps a decision log from becoming a marketing claim or a substitute for project-specific judgment.

Tie the Log to Revision Control

A decision log becomes much more useful when it points to a current project record. Do not write “approved design” without identifying the revision and intended release. A proposal can be current for a customer conversation while a technical package is still in development. A purchasing instruction can be current for a listed equipment set while a field release requires another check.

When the underlying work changes, retain the prior entry and link a new decision or disposition. Do not overwrite the evidence of what was known at the earlier release. A good entry can say that it was superseded by a later revision, why the basis changed, and whether the customer or downstream team received the change. This preserves history while allowing the project to move forward.

The Solar Designing product page describes a connected design workflow. In a product evaluation, ask the presenter to show where the current revision and outputs can be found. It cannot decide whether a changed roof condition, utility direction, or equipment substitution needs technical, commercial, or qualified review. The log gives the people responsible for that judgment the context they need.

Use Reopen Triggers Instead of “Final” Labels

Projects change. A decision log should expect that rather than attempting to freeze a project with one word. Typical reopen triggers include:

1. a site observation that conflicts with the preliminary basis;
2. a customer request that changes the scope or decision objective;
3. a utility, authority, or owner instruction that affects the assumed route;
4. an equipment substitution, price change, or availability issue;
5. updated consumption data or operating information that changes the modeled scenario;
6. a review finding that identifies a condition outside the original decision boundary.

The trigger needs a corresponding action. “Re-review layout and customer proposal if the survey changes usable area” is actionable. “Review if needed” is not. Where the issue concerns safety, code, utility, structural, or electrical matters, route it through the appropriate qualified process rather than treating the log as a decision authority.

Make the Log Useful to Customers Without Exposing Internal Noise

The internal entry may contain an operational detail a customer does not need. The customer should still receive a clear translation when a decision affects their proposal. For example: “We have prepared an initial option from the information available; the site review will confirm the conditions listed before final configuration.” That statement is precise without overloading a buyer with internal process language.

Avoid converting a documented decision into a promise. A record of a production model does not guarantee production, savings, approval, schedule, or final price. A record of an equipment choice does not guarantee availability. State the decision scope and the next verification plainly.

Review the Log for Process Improvement

Once a month, scan closed or advanced projects for recurring reopened decisions. Do equipment substitutions repeatedly arrive after proposal? Are roof assumptions being treated as field facts? Do production assumptions fail to reach the sales conversation? Are utility questions appearing after a customer date has been discussed?

Use the pattern to improve one upstream step: a better intake prompt, a clearer proposal field, a source-date requirement, or a named reviewer. Do not treat internal history as an industry benchmark. It is evidence about your own workflow and is most useful when it changes the next similar project.

Practical Next Steps

1. Add a six-field decision entry to the workflow for material choices.
2. Link each entry to the revision it controls and the evidence it relied on.
3. Define reopen triggers so a changed condition creates an accountable review, not an email hunt.

Frequently asked questions

What is a solar design decision log?

It is a concise record of a material project choice, its evidence, owner, affected revision, and reconsideration trigger. It explains why the team chose a path without replacing drawings or technical review.

Which decisions belong in a solar decision log?

Log decisions that can affect layout, equipment, production modeling, cost, customer scope, procurement, compliance route, or field work. Routine drafting edits do not need the same treatment.

Does a decision log make a design final?

No. It documents the basis for a decision at a particular stage. New site evidence, a utility instruction, a scope change, or a required technical review can still change the project.