Quick Answer
A solar design decision log records the decision, the options considered, the evidence available at the time, the owner, the revision affected, and the event that requires reconsideration. It gives sales, design, procurement, and field teams a usable history without turning every project into paperwork.
The most expensive solar-project question is often asked after the person who made the choice is no longer in the room: “Why did we do it this way?” 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.
Direct Answer
Log a solar-project decision when it can change technical configuration, price, scope, production modeling, procurement, compliance route, or field execution. Tie the entry to the controlling revision, cite the available evidence, name the decision owner, and state the event that would reopen it. A decision without a visible basis is difficult to hand over safely.
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.
NREL’s photovoltaic research makes clear that PV outcomes depend on many technical and operational variables. Project teams do not need to record every variable in a log. They do need to retain the logic behind the choices that materially affect the next decision. The log is a bridge between information and accountable action.
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.
| Decision type | Example | Why it merits a log entry |
|---|---|---|
| Layout basis | Initial arrangement prepared from imagery pending site confirmation | A later survey may change area, obstructions, or design route |
| Equipment basis | Proposed inverter or module family selected for a stated scenario | Availability or technical review may require controlled substitution |
| Modeling basis | Consumption, tariff, loss, or export assumption used in a proposal | The customer-facing scenario depends on the input |
| Scope boundary | Electrical, roofing, access, or civil work included or excluded | Price and field expectations can diverge without clarity |
| Authority route | Project is proceeding under a named permit or utility assumption | Published rules and project instructions are not interchangeable |
| Exception | Team accepts a non-standard sequence or request with a review boundary | The exception must not silently become the standard |
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 best decision log is useful during a handoff. Keep it concise and link to source files rather than copying their contents.
| Field | Question to answer |
|---|---|
| Decision | What exactly was chosen or deferred? |
| Purpose | Which project decision does it support? |
| Basis | What source documents, observations, or assumptions informed it? |
| Owner and date | Who made or approved the choice, and when? |
| Affected record | Which proposal, layout, model, material list, or release revision is controlled? |
| Reopen trigger | What new condition requires a further review? |
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.
Keep Project Decisions Attached to the Work They Affect
See how SurgePV supports connected solar design, Shadow Analysis, generation and financial modeling, and customer-facing proposals while your team keeps control of project decisions and reviews.
Book a DemoBring an active revision or handoff question to a live walkthrough.
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, update the decision rather than leaving a misleading historical label. 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. A platform can make revisions and outputs easier to locate. 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:
- a site observation that conflicts with the preliminary basis;
- a customer request that changes the scope or decision objective;
- a utility, authority, or owner instruction that affects the assumed route;
- an equipment substitution, price change, or availability issue;
- updated consumption data or operating information that changes the modeled scenario;
- 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
- Add a six-field decision entry to the workflow for material choices.
- Link each entry to the revision it controls and the evidence it relied on.
- Define reopen triggers so a changed condition creates an accountable review, not an email hunt.
Ready to Make Solar Project Decisions 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 design decision log?
It is a short record of a material project choice, why the team made it, what evidence supported it, who owns it, which revision it affects, and what event requires reconsideration. It supplements rather than replaces technical records and review.
Which decisions belong in a solar decision log?
Include choices that can change layout, equipment, modeling, commercial scope, procurement, compliance route, or field work. Routine minor drafting edits do not normally need the same structure.
Does a decision log make a design final?
No. It records a decision basis at a point in time. New evidence, site conditions, qualified review, utility direction, or a customer scope change can reopen the decision.
