The Proposal Revision Checklist After a System-Size Change

The array loses several modules after a roof obstruction is confirmed. A coordinator updates the system size on the proposal cover, replaces the layout image, and saves a new PDF. Farther down, the equipment count, modeled production, financial scenario, scope table, and comparison language still describe the earlier design.

The document looks revised because its most visible page changed. The customer can still receive two projects inside one file.

Use the proposal revision checklist after system-size changes to prevent that split. It traces one authorized design difference through every field, claim, image, scenario, review, and release that the customer may rely on. It also records which content was checked and found unaffected, because a blank review cell cannot distinguish “no impact” from “nobody looked.”

This page is deliberately narrow. The solar design revision impact checklist owns the full dependency trace across design, production, financial, proposal, and delivery records. The single design-to-proposal revision workflow owns the shared change state from request through closure. This guide begins after a system-size change has been authorized and asks whether one successor proposal is ready for controlled customer release.

This is an operating guide for proposal coordinators. It does not design a project, calculate production or savings, select equipment, set price, interpret a contract, approve financing, establish customer consent, or replace engineering, code, utility, permitting, legal, tax, lender, insurer, or other qualified review.

What changes when a solar system size changes?

A solar system-size change can alter more than the capacity value printed on a proposal. It can affect design identity, module and equipment descriptions, model inputs, production outputs, usage comparisons, financial scenarios, price and scope, customer choices, review states, and released files. The coordinator must trace dependencies before deciding which proposal fields need revision.

Start by defining size precisely. A project can carry several related values: module count, module rating, array DC capacity, inverter or conversion capacity, storage scope, and the identity of the design option. A rounded headline value may be suitable for one customer display while the governed model or equipment schedule uses more precise inputs. Record the basis and unit instead of treating “size” as a self-explanatory field.

The U.S. Department of Energy’s photovoltaic system design overview describes modules, mounting, orientation, inverters, storage, and balance-of-system technologies as connected parts of PV system design. That general context supports a dependency review beyond the capacity label. It does not choose a private configuration, determine project feasibility, or approve a revision.

A size change may begin with a customer request, site evidence, design review, equipment substitution, utility condition, or a corrected input. The trigger matters because it establishes authority and scope. A coordinator should know whether the team is evaluating a possible option or implementing an accepted change. A proposal released during evaluation must not imply that the new configuration has completed reviews it has not earned.

Use four identities at the start:

Do not let the most recent timestamp decide which identity controls. A draft created today may be based on yesterday’s design. A reviewed proposal created earlier may remain the current customer release until a successor clears its own gate. “Latest” answers a file-system question, not a release question.

NASA’s configuration-management reference describes making product configuration known, distinguishing versions, controlling baseline changes, tracking changes, and keeping products consistent with information about them. NASA does not prescribe a solar proposal process. The analogy gives the coordinator a useful test: can the team identify the predecessor, successor, change authority, and customer-facing state without opening several folders and guessing?

Proposal impact starts with changed objects

Describe what changed as governed objects and fields. “System downsized” is too vague to drive review. Name the removed or added modules, changed geometry, equipment relationship, model option, customer selection, or other accepted difference. Link the source evidence and the role that authorized its use.

Then map consumers. A module-count field may feed the cover, system summary, equipment table, layout caption, model, price schedule, and scope narrative. A successor does not become coherent because those values happen to look close. Each consumer needs an updated value, a reviewed no-impact disposition, an explicit unknown, or a not-applicable finding.

How do you use a proposal revision checklist after system size changes?

Review twelve proposal areas after a system-size change: revision identity, size basis, layout and equipment, model provenance, production output, usage comparisons, financial scenarios, price and scope, customer claims, option comparisons, qualifications, and release control. Each area needs an impact disposition, evidence, owner, and successor value before customer release.

The checklist is a release screen, not permission for a proposal coordinator to make every underlying decision. Designers control design records within their authority. Model, finance, pricing, contract, and qualified technical owners decide their fields. The coordinator connects accepted decisions and stops release when the customer-facing artifact mixes states.

1. Revision identity and active customer option

Confirm the project, site, customer option, predecessor proposal, successor proposal, predecessor design, successor design, and shared revision or change id. If the proposal compares options, identify which option changed and whether the comparison basis must also change.

The first page, filename, internal record, and live access route should point to one successor. Retain the predecessor for history. Do not quietly reuse its version id after replacing content.

2. System-size basis and displayed units

Record the exact accepted source for module count, module rating, array capacity, inverter or conversion capacity, and any storage value shown. Confirm the display unit, precision, and rounding rule for each location. The proposal should not show one rounded capacity in the summary and a contradictory value in the equipment or financial section.

The checklist does not prescribe which capacity basis every company must feature. It requires the proposal to name and use its chosen basis consistently, with the governed technical source retained behind it.

3. Layout images, counts, and equipment descriptions

Replace or disposition every layout image, module count, equipment quantity, system diagram, caption, and descriptive sentence that consumes the prior design. Confirm that alt or accessibility text, download labels, and option names do not preserve an old count or configuration.

If the size change affects materials, route the project through the BOM update trigger checklist. If it can affect electrical representation, route it through the SLD review trigger guide. A proposal release does not close either technical review.

4. Model run and input provenance

Record the active model run or scenario id, input sources, design revision, equipment basis, resource data, shading treatment, configuration, author, review state, and run time. If the prior model remains valid, the model owner should state why the changed design object is outside its dependency boundary.

The Sandia National Laboratories PV Performance Modeling Collaborative modeling guide describes a process from weather, irradiance, module, and system-design inputs through intermediate calculations and system output power. The guide does not validate a private model or proposal. It supports the dependency principle: a changed input needs a documented model disposition before an older output is reused.

5. Production output and explanatory language

Update or confirm every production value, chart, monthly series, annual summary, unit, loss statement, comparison, and explanatory sentence drawn from the model. Keep the source model id near enough in the controlled record that a reviewer can reproduce the proposal’s basis.

Solar resource context also matters. DOE says in its solar radiation basics that radiation reaching a location varies with geography, time of day, season, local surroundings, and weather. That public explanation does not approve a project dataset or output. Do not turn a size ratio into a production estimate by assumption.

6. Energy-usage and self-consumption comparisons

Check every comparison between modeled production and customer usage, including charts, coverage language, export or self-consumption scenarios, and load-shape notes. A change in proposed output can alter the comparison even when the usage source remains unchanged.

Preserve usage-file identity and time coverage. If the proposal uses several meters, sites, or customer options, confirm that the successor production belongs to the same comparison group. A neat percentage is not trustworthy when its numerator and denominator describe different scenarios.

7. Financial scenarios and assumptions

Route affected production, size, equipment, price, and usage values to the assigned financial owner. Check savings language, cash-flow views, payback or return displays, financing scenarios, escalation assumptions, incentive inputs, residual values, and every chart or sentence that consumes them.

The coordinator should not recalculate or approve financial outputs outside their authority. Record the accepted scenario id, input versions, reviewer, limitations, and intended customer use. If a current incentive, tax, tariff, financing, or jurisdiction-sensitive item appears, require current qualified evidence and review for the named location.

8. Price, scope, quantities, and commercial terms

Confirm price basis, included equipment, quantities, labor or service scope, allowances, exclusions, payment schedule, validity, change route, and any contract-facing statement. A lower or higher system size does not prove how price changes. Commercial owners must provide the accepted successor values.

Keep quoted scope connected to proposal scope. If an external written quote, contract, financing document, or procurement record controls a field, link it and preserve its authority. A proposal generator must not invent a successor price from a changed capacity value.

9. Customer-facing objective claims

Review every objective statement that may change with the design, model, financial scenario, equipment, or scope. That includes claims embedded in captions, comparison boxes, callouts, footnotes, charts, and follow-up material distributed with the proposal.

The U.S. Federal Trade Commission’s small-business advertising guide says advertising must be truthful and non-deceptive and advertisers need evidence to support claims. This general United States guidance is not legal advice or approval of a solar proposal. It supports one release control: do not carry a prior objective claim into a successor without checking its evidence against the changed project state.

10. Option comparisons and recommendation language

If the proposal compares system options, update the changed option and every relative statement about the others. Confirm that images, counts, outputs, prices, scope, and assumptions are compared on a declared basis. A revised option can make an earlier ranking or recommendation stale even when the unchanged option retains its own values.

Separate customer choice from technical acceptance. A customer may prefer the larger or smaller option, while qualified owners still need to confirm whether it can proceed. Record the decision the comparison supports and the limitations that remain open.

11. Assumptions, qualifications, and next steps

Revise assumptions, exclusions, open conditions, survey needs, equipment availability notes, approval boundaries, and proposed next actions. Remove limitations that no longer apply and add those created by the new option. Do not bury a known contradiction in a general disclaimer.

The next step should match the successor’s real state. A preliminary option can invite evidence review or customer discussion. It should not invite contract, financing, permit, procurement, or installation reliance that the current review state does not support.

12. Release, recipients, and supersession

List the final proposal version, design and scenario ids, reviewers, release authority, named purpose, recipients, links, attachments, issue time, and expiry or next review point. Identify every known predecessor recipient and live access path. Record whether the older artifact was withdrawn, replaced, expired, or qualified.

Release is an event, not a saved file. Capture who approved the customer-facing successor and which accepted evidence they checked. If a prior proposal was already used in a meeting or forwarded to another decision maker, the communication route belongs in the revision record.

How should a coordinator run the proposal revision check?

A proposal coordinator should freeze the predecessor, register the authorized size change, build a field-level impact matrix, collect accepted successor outputs, compare the proposal against its source records, obtain responsible reviews, and control release and supersession. The check closes only when every applicable field has a disposition and every known recipient route is addressed.

Run the checklist in eight steps:

1. Freeze the customer-facing predecessor. Preserve the exact released file, live link state, recipients, purpose, issue time, and the design, model, commercial, and customer option it represented. Do not begin by editing the only retained copy.

2. Register the authorized difference. Record the trigger, evidence, requester, decision authority, prior size basis, successor size basis, changed objects, affected option, and intended customer decision. Separate a proposed option from an accepted revision.

3. Create the impact matrix. Add the twelve checklist areas and assign impact confirmed, no impact confirmed, unknown, or not applicable. Name the evidence and role required to close each row.

4. Update controlled sources before presentation. Ask each responsible owner to update or accept the design, model, financial scenario, price, scope, and other source records within their authority. Do not patch proposal values around stale sources merely to make the file appear consistent.

5. Generate the successor from accepted records. Create a new proposal version tied to the successor design and scenarios. Preserve manual edits as declared exceptions with an owner and reason, because a later regeneration can otherwise erase them.

6. Compare field by field. Review the predecessor, successor, and governed sources. Confirm identity, units, precision, labels, images, counts, outputs, commercial fields, claims, limitations, and next steps. Inspect downloadable and shared forms as well as the editor screen.

7. Obtain review and release authority. Each owner accepts the fields within their responsibility. The release owner verifies that the complete customer artifact describes one coherent option and that unknowns impose the right restrictions.

8. Issue, replace, and verify. Release the named successor for its allowed use. Replace or withdraw known predecessor routes, notify recipients where required, capture receipts or delivery events, and verify that customer-facing links resolve to the intended version.

The eight-step process is deliberately stricter than “update and resend.” A coordinator can complete every editing task and still lack a release if a model, price, claim, or customer route remains unresolved. The final state should say released, released with named conditions, held, or rejected. “Revised” does not reveal whether anybody may use it.

NASA’s requirements-management guidance describes bidirectional traceability and says proposed baseline changes should be evaluated for impacts across cost, schedule, architecture, design, interfaces, operations concepts, and related requirements. NASA writes for its own systems programs, not solar proposal teams. The analogy supports tracing a changed design basis in both directions: back to the authority and evidence behind it, then forward to every customer-facing consumer.

Close rows with evidence, not a colored checkbox

An impact matrix becomes useful only when a reviewer can inspect the reason behind each disposition. For an updated production chart, keep the successor model id, accepted source state, proposal location, reviewer, and observed rendered value. For a no-impact field, state which dependency was checked and why the predecessor value remains valid. For unknown, name the blocked use and closure event.

Compare the source-to-display chain as well as the predecessor-to-successor difference. A predecessor redline shows what changed between documents, but it cannot prove that the new value came from the accepted source. A source comparison can show the correct value, but it may miss an old caption or attachment. The release check needs both views.

Ask reviewers to accept bounded fields instead of signing a vague document-wide approval outside their authority. A model owner can accept the model id and output carried into the proposal. A commercial owner can accept price and scope. The release owner then verifies that those accepted pieces appear together in the intended customer artifact, without becoming the engineer, modeler, finance owner, or contract authority.

If a field is copied manually, record that fact and test what happens on regeneration. The proposal may look correct today and revert during the next update because its governed source still contains the predecessor value. Repair the source when possible. When a manual exception must remain, give it an owner, review point, and explicit retirement condition.

Compare the rendered proposal with its source fields

Generated output can expose differences that source-field review misses. Inspect charts, pagination, captions, table totals, footnotes, option ordering, broken references, truncated labels, accessibility text, downloaded files, email attachments, and public or customer links. Confirm that the displayed artifact carries the intended date and version.

If the platform supports interactive options, test the state the recipient sees when opening a saved link. A proposal coordinator should not assume that the editor’s current view matches a link created for the predecessor. Record the observed successor route and issue time.

How should unknowns and exceptions be handled?

Keep an unresolved proposal impact visibly unknown, identify the missing evidence or authority, assign an owner, restrict dependent uses, and set the event that will close it. Treat manual overrides, preliminary releases, reviewed no-impact decisions, and rejected changes as separate states. An exception should narrow permission, not turn uncertainty into an accepted customer claim.

A proposal may need to support a discussion before every project decision is complete. That can be responsible when its purpose, recipients, open conditions, prohibited uses, reviewer, expiry, and successor path are visible. Preliminary does not mean unreviewed. It means reviewed for a narrower purpose.

Use the following exception routes:

Do not use a general disclaimer to cover a field the team knows is wrong. Either correct it, remove it, replace it with bounded language supported by the current state, or hold the release. A limitation is useful when it describes a real boundary, not when it asks the customer to discover the contradiction themselves.

Illustrative example, not a customer case

A site review confirms that one roof area cannot support the proposed module layout. The authorized successor has fewer modules. The proposal coordinator freezes the released predecessor, registers the changed design objects, and opens the twelve-area matrix.

The layout, module count, system summary, modeled output, usage comparison, price, and customer comparison show confirmed impact. The equipment description is under review because the new configuration may change a dependent selection. Contract and incentive fields are marked not applicable because this discussion-stage proposal contains neither. No-impact is not assumed for any blank row.

The model owner issues a successor run tied to the new design. The commercial owner supplies the accepted price and scope. The proposal coordinator regenerates the file, finds an old system-size reference in a chart caption, corrects it at the governed source, and repeats the rendered comparison. The release owner holds distribution until the equipment description receives its disposition.

This scenario is illustrative. It states no customer, system quantity, production, savings, price, schedule, approval, error rate, or product outcome. Its lesson is about release order: source decisions first, customer presentation second.

What should the copy-ready revision record contain?

A copy-ready system-size proposal revision record should preserve predecessor and successor identities, the authorized size difference, source evidence, twelve impact dispositions, accepted replacement values, reviewer decisions, rendered comparisons, release purpose, known recipients, supersession actions, and open conditions. It should show both what changed and what a responsible owner checked and retained.

Copy this record into a controlled CRM object, revision ticket, or proposal-release form. Adapt access, retention, customer communication, consent, contract, and technical authority to the company and project.

SYSTEM-SIZE PROPOSAL REVISION ID:
Project, site, and customer option:
Coordinator:
Change trigger and source evidence:
Requester and decision authority:
Requested customer decision:

PREDECESSOR
Design revision and size basis:
Model run and scenario ids:
Financial and price scenario ids:
Proposal version, issue time, purpose, and status:
Known recipients, links, and attachments:

AUTHORIZED SUCCESSOR
Design revision and size basis:
Changed objects and fields:
Reason and accepted evidence:
Affected customer option:
Authority and decision time:

IMPACT MATRIX
For each area record: impact / no impact / unknown / not applicable
1. Revision identity and customer option:
2. System-size basis and displayed units:
3. Layout, counts, and equipment descriptions:
4. Model run and input provenance:
5. Production output and explanatory language:
6. Usage and self-consumption comparisons:
7. Financial scenarios and assumptions:
8. Price, scope, quantities, and commercial terms:
9. Customer-facing objective claims:
10. Option comparisons and recommendations:
11. Assumptions, qualifications, and next steps:
12. Release, recipients, and supersession:
For every applicable row: source / predecessor value / successor value / owner / evidence / review state / restrictions

SUCCESSOR REVIEW
Proposal version:
Design, model, finance, price, and scope sources:
Manual overrides and regeneration risk:
Rendered comparison completed by and at:
Required reviewers and decisions:
Unknowns, prohibited uses, and closure events:

RELEASE AND SUPERSESSION
Release decision: release / conditional release / hold / reject
Allowed purpose and recipient group:
Release authority and issue time:
Delivery or receipt evidence:
Predecessor withdrawal, replacement, expiry, or qualification actions:
Customer correction or explanation owner:
Open condition owners and review points:
Closure verification and time:

The record is intentionally detailed because the failure is distributed. One field changes in design, another in a model, another in a commercial tool, and another in a PDF or shared link. If the organization governs part of this information elsewhere, reference that source rather than copying an uncontrolled value into the checklist.

Review recurring misses after several revisions. If system-size changes repeatedly leave stale chart captions or option comparisons, fix the source mapping or release test. Do not turn a recurring defect into an invented frequency or performance claim without a complete, defined dataset.

Where can SurgePV support proposal revision work?

SurgePV can support connected 3D roof modeling, solar array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. It does not authorize size changes, verify every source, approve engineering or commercial decisions, control external recipients, interpret contracts or codes, or guarantee revision correctness, customer acceptance, savings, production, or approval.

A connected project workspace can help proposal teams keep layout, model, electrical, materials, and proposal artifacts associated with the active project option. Teams can examine Solar Designing during an approved revision route. The company still needs a change authority, field owners, review rules, release purpose, and supersession process.

Product outputs depend on source data, assumptions, equipment records, configuration, and review. Responsible engineers, authorities, lenders, insurers, utilities, customers, commercial owners, and other qualified reviewers retain their decisions. Written quotes and contracts control their respective commercial terms.

Evaluate the workflow with a real change. Ask how the system identifies active scenarios, carries accepted size changes into connected outputs, exposes assumptions, retains revisions, and supports proposal generation. Then test how your surrounding systems record recipients, withdrawals, consent, approvals, and closure. Software generation and customer release are different events.

Release one successor, not a patched predecessor

A system-size change makes stale content easy to spot only when the capacity value is wrong. The harder defects are plausible: an earlier model that still has a professional chart, a comparison whose labels still read well, or a customer link that opens without warning.

Freeze the predecessor. Define the successor. Trace all twelve proposal areas, including reviewed no-impact decisions. Update controlled sources before presentation, compare the rendered artifact, and treat recipient replacement as part of release.

The checklist does not promise that the revised project is viable or approved. It gives the proposal coordinator a defensible answer to a narrower question: does this customer-facing successor describe one accepted option, with its unknowns and authority boundaries still visible?

Frequently Asked Questions

Does every solar system-size change require a revised proposal?

Every accepted system-size change needs a documented proposal-impact decision. A revised proposal is required when the change affects customer-visible design, equipment, modeled output, financial analysis, price, scope, assumptions, comparisons, or commitments. If the proposal is unaffected, record the reviewed reason and reviewer instead of treating silence as proof.

What should be checked first after the system size changes?

Freeze the current released proposal and identify the authorized predecessor and successor design states. Record the size basis, unit, equipment configuration, reason, source evidence, affected customer option, and change authority. Do not edit customer-facing values until the team knows which accepted design and model run the successor proposal must represent.

Can the old production estimate stay in a revised solar proposal?

Keep an earlier production estimate only when the responsible model owner confirms that the system-size change does not affect any consumed input or output and records that decision. When the change affects geometry, equipment, configuration, shading treatment, or another model input, rerun and review the affected model before the proposal uses its output.

Who should approve a revised solar proposal?

Approval belongs to the roles responsible for each changed field and the final customer-facing release. Design and modeling owners review their inputs and outputs. Commercial owners review price and financial content. The proposal release owner verifies one coherent successor. Qualified engineers, authorities, lenders, insurers, utilities, and contract reviewers retain their own decisions.

How should a superseded proposal be handled?

Retain the superseded proposal for history, mark its release state, link it to the successor, and identify every known recipient or live access route. Withdraw, replace, expire, or qualify earlier copies according to company policy and the communication required. A new filename alone does not prevent an earlier customer artifact from remaining active.