6 Solar Revisions That Need Design Approval

“Can you just move those panels to the other roof?” sounds like a presentation request. In a proposal workflow, it can be a new design request wearing the clothes of a cosmetic edit. The move may change usable geometry, shade, capacity, electrical relationships, modeled production, equipment quantities, price basis, and what the customer believes has been reviewed.

The proposal coordinator should not have to decide those consequences alone. Six revision categories need to return to the design owner before the document is resent. The objective is not to make every wording edit slow. It is to keep a customer-facing document from becoming a second, unofficial design environment.

This article is not engineering, structural, electrical, safety, utility, permitting, finance, tax, contract, consumer-protection, or legal advice. “Design approval” here means workflow acceptance by the company’s designated design owner. It never substitutes for any additional qualified professional or authority review required for the real project.

The electrical revalidation trigger guide owns electrical revalidation after a design change. The proposal revision mistake guide owns conflicting answers across documents. This page owns the earlier routing decision: which requests must leave the proposal queue and return to design before resend.

What makes a proposal revision a design change?

A proposal revision becomes a design change when it alters or could invalidate controlled geometry, placement, equipment, capacity, shading, loss, energy yield, electrical relationships, site inputs, materials, or a commercial output derived from them. Route by dependency, not by how small the customer’s wording sounds. If design meaning might change, hold resend until the responsible owner decides.

Start with the current released state. Identify the proposal version, design version, equipment set, model run, site-evidence set, commercial basis, and customer decision the document supports. A request has no reliable impact assessment when the team cannot say what it is changing.

Use a routing test:

NASA’s configuration-management guidance discusses configuration identification, change management, status accounting, and verification in NASA programs. It does not define a solar proposal process. The useful analogy is to make the controlled state and approved change visible rather than allowing a document edit to redefine the product silently.

An edit can be small on the page and large in the dependency graph. Deleting one module changes a count. That count may drive nameplate capacity, equipment quantities, modeled yield, materials, price, and financial outputs. The coordinator needs a routing rule that sees those relationships before the PDF is regenerated.

Separate request authority from approval authority

Customers, sales representatives, installers, managers, lenders, or partners may request a revision. A requester’s importance does not grant design authority. Record the desired outcome, reason, evidence, priority, and customer consequence without promising that the requested implementation is feasible or approved.

The design receiver can accept the request for evaluation, reject it with a reason, ask for evidence, propose a bounded alternative, or route another qualified owner. Receiving the request is not the same as approving the result.

Which six revision requests require design approval?

Require design approval for six categories: module layout changes, equipment or capacity changes, shading and yield changes, electrical configuration changes, site or mounting evidence changes, and commercial revisions driven by design outputs. Each request can affect several records at once. Design must assess dependencies, regenerate affected outputs, and release one controlled revision before sales resends it.

1. Moving, adding, removing, or rotating modules

Any module-placement request changes the released layout. It may affect roof-plane use, orientation, access paths, spacing, shade relationships, module count, nameplate capacity, equipment configuration, materials, production, appearance, and customer expectations.

Do not redraw the proposal illustration while leaving the technical design unchanged. Nor should sales promise that a customer-preferred placement is feasible because it looks open in an image. Submit the desired outcome, affected area, current evidence, and reason to design.

The design owner determines what current geometry, site evidence, procedure, and additional review apply. If an alternative is approved, connect the released layout to every dependent output and retire the prior customer-facing version.

2. Changing module, inverter, battery, quantity, or system capacity

Equipment substitutions and quantity changes can alter ratings, compatibility questions, electrical relationships, space, materials, model inputs, price, and documentation. The proposal coordinator should never swap a product name and copy the old capacity or performance values forward.

The Department of Energy’s PV system design overview explains that modules are one part of a complete photovoltaic system with other technologies and components. It does not approve any equipment combination. A qualified design and electrical workflow must assess the actual change.

Route customer brand preferences, availability problems, procurement substitutions, and price-driven alternatives through the same controlled request. Commercial pressure does not reduce the need to understand what else the equipment change invalidates.

3. Revising shade, loss, or energy-yield values

A request to “make the production match the new panel count” is not a text edit. Modeled yield depends on an input set, model, scenario, and review state. Changes to geometry, equipment, shade, system losses, weather data, availability assumptions, degradation, or usage context can require a new model run.

Do not scale the old annual number mentally or by an undocumented ratio. Do not type a customer-requested yield into a chart. Route the changed input and evidence to the model owner, retain the old run, and release the new result only after its inputs and limitations are reviewed.

The proposal should name modeled values as modeled. Design approval does not turn a forecast into guaranteed production. The production-estimate explanation guide helps keep model inputs and customer claims separate.

4. Changing inverter relationships, stringing, service, storage, or electrical scope

Any request that changes inverter selection, module-to-inverter relationships, string configuration, service assumptions, battery configuration, backup scope, electrical equipment, route, or single-line content needs the responsible electrical and design workflow.

The proposal team can record the requested customer outcome, such as adding storage or preserving an equipment location preference. It should not decide electrical feasibility, capacity, code compliance, interconnection, protection, backup behavior, permit acceptance, or required scope.

Route the request with the current design, evidence, equipment state, and exact customer question. The electrical revalidation trigger guide provides a deeper checklist. Design workflow approval and professional electrical approval remain distinct decisions where applicable.

5. Incorporating new roof, structure, mounting, access, or field evidence

A site visit may add a measurement, photograph, roof-work history, obstruction, surface condition, access limit, route observation, or conflict with remote imagery. Proposal coordinators should not decide which source wins or edit the design to match the newest note.

Route the finding with provenance: project, location, date, observer, method, unit, direction, subject, source state, limitation, and affected assumption. A photograph without identity is not a change instruction. A customer statement can open a question without becoming a structural or electrical conclusion.

The Department of Energy’s rooftop permitting and inspection page describes permitting and inspection as local processes addressing applicable safety and code requirements. It does not establish the path or result for a property. Keep authority and qualified-review decisions outside the proposal queue.

6. Revising price, scope, payment, or schedule because the design changed

A request may appear commercial: lower the price after removing modules, add a storage option, change payment figures, promise a different installation scope, or give the customer a new date. When the value depends on a design change, commercial review must wait for a released design basis.

Do not assume a smaller system produces a proportional price, payment, yield, savings, or schedule change. The affected equipment, materials, labor, electrical work, commercial rules, financing, tax treatment, utility process, and contract terms may not scale together.

Design approval does not approve price or finance. It supplies the current technical basis to the responsible commercial, finance, contract, and customer-communication owners. Each decision keeps its own source and approval.

How should a revision move through design approval?

Freeze the current proposal and design versions, convert the request into a structured change record, map affected dependencies, obtain missing evidence, let design and other qualified owners evaluate it, regenerate every stale output, run independent review, and release one version to sales. The receiver must explicitly accept or return the package; a completed task status is not approval.

Use this sequence:

1. Preserve the request verbatim. Keep the requester’s words, source, date, reason, desired outcome, and customer impact.
2. Freeze the current state. Record proposal, design, layout, equipment, model, field evidence, price basis, and artifact hashes.
3. Classify the change. Mark geometry, layout, equipment, model, electrical, site, commercial, claim, or multiple categories.
4. Map dependencies. Identify every output that may become stale, including diagrams, tables, materials, production, price, and narrative claims.
5. Ask for bounded evidence. Do not request an entire new survey when one identified record can resolve the question.
6. Obtain responsible decisions. Design, engineering, electrical, structural, utility, permitting, commercial, finance, contract, and legal approvals remain separate where applicable.
7. Regenerate from controlled sources. Never patch only the visible field while dependent values remain old.
8. Run independent comparison. Compare approved request, prior state, new state, dependencies, customer claims, and release criteria.
9. Issue one disposition. Approve, approve with named conditions, reject, request evidence, offer an alternative, reroute, or stop.
10. Release one customer version. Mark prior documents superseded and give sales the approved explanation and open limitations.

NASA’s technical-data management guidance discusses planning how data are acquired, identified, accessed, managed, protected, and used in NASA work. This is a process analogy only. A solar revision package similarly needs identifiable evidence, controlled access, and a known consumer rather than scattered attachments and messages.

Use an approval matrix:

What can sales change without design approval?

Sales may use a bounded editorial path for a correction that changes no technical meaning, number, image, equipment, scope, assumption, model, site statement, approval state, or design-dependent commercial claim. The content owner should compare the exact before and after text. When meaning or dependency is uncertain, route design instead of guessing that the edit is cosmetic.

Examples that may qualify after controlled review include correcting a contact detail from an approved source, repairing a spelling error, or updating meeting logistics that do not imply a project schedule. Even these changes need identity, privacy, version, and release controls.

Examples that look editorial but are not:

• Changing “preliminary” to “final” alters the approval claim.
• Changing a unit or decimal changes the numeric meaning.
• Replacing an equipment label can create a product substitution.
• Cropping or swapping a layout image can hide a different design state.
• Rewording “modeled production” as “your production” changes the evidence posture.
• Changing “subject to review” to “approved” changes authority.
• Editing a date can become a schedule or offer promise.

NASA’s technical-assessment guidance discusses evidence, measures, status, variances, risks, and corrective action in NASA technical work. It is not a solar release standard. The analogy is to compare the proposed change with the controlled requirement and record the variance, rather than approving it because the file still renders.

Give the coordinator a safe stop sentence

The coordinator needs approved language when a requester pushes for immediate resend:

“This request changes a design-dependent field, so I cannot release it as a document-only edit. I have preserved your requested outcome and routed the affected design, model, electrical, site, and commercial dependencies to their owners. I will issue the approved version or a specific return reason after receiver acceptance.”

That sentence is not a delay tactic. It names the control and promises only a disposition the workflow can support.

What copy-ready record controls the resend?

Use a revision approval and resend record that preserves the request, current versions, change category, affected dependencies, evidence, decisions, regenerated outputs, independent comparison, customer explanation, and release hash. The record must distinguish design acceptance from every additional professional or commercial approval. Sales receives one approved artifact and a list of claims that remain conditional.

Copy-ready design approval and resend record

Illustrative example, not a real customer, project, design, equipment set, model, price, revision, approval, or result. A customer asks to move modules from a visible roof plane and add storage. Sales records the preference and does not edit the proposal image or insert a battery price.

Design receives the current layout, equipment set, model run, site evidence, and exact requested outcome. The request marks layout, capacity, shade, yield, electrical, material, price, and claim outputs stale. Responsible owners evaluate the alternative and identify missing evidence.

The coordinator receives one disposition. If an alternative is released, all affected outputs share the approved source versions and the old proposal is superseded. If the request is rejected or held, the customer receives the reason and next evidence step without a feasibility, cost, production, schedule, or approval promise.

The solar design review checklist supports the design comparison. The sales-to-design handoff guide supports receiver acceptance. The revision record connects both controls to the customer-facing resend.

SurgePV’s repository-verified scope includes 3D roof modeling, solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, integrations, and review.

SurgePV can help keep design and proposal outputs connected across a revision. It cannot approve engineering, structural, electrical, utility, permitting, commercial, financial, contract, tax, or legal decisions, guarantee an integration, or guarantee production, price, savings, schedule, approval, or customer results.

A fast resend is not the one that leaves the queue first. It is the one that does not return later with a second answer. Route the change by dependency, preserve the old state, obtain the right decisions, and give the customer one version the team can explain.

Frequently Asked Questions

What does design approval mean before resending a proposal?

Design approval means the designated design owner has reviewed the controlled request, current evidence, affected dependencies, regenerated outputs, exceptions, and release purpose, then accepted the revision under the company’s procedure. It does not replace engineering, electrical, structural, utility, permitting, finance, contract, or authority approval where those separate qualified decisions are required.

Can sales move solar panels in a proposal to match a customer preference?

Sales can record the preference and explain why a design review is needed, but should not create a new customer-facing layout by moving modules independently. Placement may affect geometry, access, shade, capacity, equipment, electrical configuration, production, materials, price, and approvals. Design should evaluate the request, document the disposition, and release any approved alternative.

Does a wording-only solar proposal revision need design approval?

Not always. A truly editorial correction that changes no technical meaning, number, label, equipment, scope, assumption, image, diagram, claim, or dependency may follow a bounded content-review path. If the wording describes system size, yield, layout, electrical scope, site condition, equipment, or approval state, route it to the responsible design or qualified owner before release.

Who should approve a solar design revision?

The company’s responsibility matrix should name the design receiver and any additional qualified reviewers. The correct owner depends on the change, project stage, market, release purpose, and jurisdiction. A designer’s workflow acceptance is not automatically professional engineering, structural, electrical, utility, permit, finance, contract, or legal approval. Record each required decision separately.

How should rejected solar revision requests be handled?

Preserve the original request, evidence, requester, reason, affected customer decision, and design disposition. Explain the result without blame or invented certainty. The team may offer an approved bounded alternative, request more evidence, route specialist review, retain the current proposal, or stop the resend. Never implement the rejected change informally in another document.