7 Solar Proposal Fields That Stay Stale After Changes

A solar proposal can have a new layout on page three and an old system summary on page one. The image changed, but the module quantity in the scope did not. Production was rerun, but the savings paragraph still describes the earlier scenario. A new equipment selection appears in the design record, while the proposal footer retains the retired model name.

These are not always calculation mistakes. They are often propagation mistakes: duplicated, transcribed, cached, pasted, or derived fields survived after their parent changed. Each value may look plausible in isolation. The conflict becomes visible only when someone compares the customer-facing field with the approved source that controls it.

This guide is a field-level spot check for proposal teams. It does not replace the full solar design change-management process, the broader design-revision impact checklist, or the end-to-end design-to-proposal revision workflow. It focuses on seven customer-facing field groups and gives each one a parent, invalidation trigger, owner, test, and release rule.

The seven are an operator-created audit taxonomy, not a measured ranking of failure frequency. Adapt the register to your proposal system, contracts, review roles, market, and project type.

A disclosed mismatch is not automatically releasable. If the required parent or technical/commercial decision is missing, retain the hold. An authorized reviewer may approve a narrower, clearly preliminary output when the intended use supports it; a note cannot replace the required decision or make conflicting facts current.

Why do proposal fields stay stale after a design change?

Proposal fields stay stale because one design fact is repeated across separate pages, exports, calculators, images, templates, and narratives. A change reaches the authoritative design record but not every dependent copy. Manual edits, cached outputs, unclear ownership, and release checks that review appearance instead of provenance allow the earlier value to survive.

The underlying issue is that a proposal contains several kinds of dependency. A direct field displays a value from a controlling record, such as a module quantity. A derived field is recalculated from inputs, such as modeled production or a financial output. A narrative field turns values and assumptions into sentences, labels, captions, or claims. A design change can invalidate all three even when only one number visibly moves.

Configuration management offers a useful mental model without turning a NASA process into a private-company requirement. NASA’s configuration-management overview discusses baselines, identification, approved changes, status accounting, traceability, consistency between a product and its information, and verification. For a proposal team, the transferable principle is modest: name the approved parent, preserve revision identity, and verify dependent information before release.

The parent must be more specific than “the design.” A capacity field might be controlled by an approved array schedule. A layout image might be controlled by a particular exported view of a named scenario. A production summary might be controlled by a model run that combines geometry, weather data, losses, and other assumptions. Pricing may depend on an estimating record that consumes equipment and scope, but also includes commercial decisions that the designer does not own.

This is why a simple timestamp is weak evidence. A file exported later can still contain an old image or cached result. “Updated” is also too vague. Record the parent ID, parent revision, generation or comparison time, reviewer, and disposition. That makes it possible to distinguish a current value from an old value that happened to be copied into a new file.

Three failure patterns deserve special attention:

• Copy persistence: a field was pasted into a text box, cover page, appendix, email, or scope note and no longer updates with its source.
• Partial regeneration: one page or calculation was refreshed, but another output using the same parent was left untouched.
• Narrative lag: the numbers changed, yet the nearby explanation, comparison, recommendation, or limitation still describes the earlier scenario.

The audit should therefore ask two questions for every field: “Does the displayed value match?” and “Can we prove which approved revision produced it?” A yes to only the first question is not enough.

Which seven fields require a stale-value audit?

Audit seven proposal field groups after a solar design change: revision identity and status; system capacity and module count; equipment names and quantities; layout visuals and placement language; production and loss outputs; scope, pricing, adders, and exclusions; and financial outputs plus their narrative. Treat every group as a dependency, not an isolated text box.

1. Revision identity, scenario, and approval status

Start with the labels that tell a reader which proposal they are viewing. This group includes revision ID, scenario name, issue date, approval or review status, option label, customer-visible version note, and any comparison label such as “recommended” or “alternate.” These fields control interpretation before the reader reaches a technical value.

The controlling parent is the approved proposal-release record tied to a named design scenario. Invalidate the group when a design scenario is duplicated, renamed, superseded, returned for changes, or approved under a new revision. Also invalidate it when the team regenerates an output after the approval state changes. A current layout under an old “approved” label is a serious provenance conflict even if the layout itself is correct.

The common symptom is a mixed identity. The cover says one revision, the layout caption names another, and an appendix has no scenario identifier. Another warning is an option label that survived after options were consolidated. The field may be stale even when the dates are recent because the release status, not the export date, is controlling.

The release owner should compare the cover, page footer, filename, scenario label, approval record, and customer-delivery record. Return the proposal if any identifier is missing or inconsistent. Release only when one approved scenario can be traced through every customer-facing page and attachment. If two options are intentionally included, each must have its own explicit boundaries and no shared label that obscures which values belong to which option.

2. System capacity and module count

Capacity and module count are repeated in summaries, badges, scope tables, layout captions, production pages, and financial pages. The controlling parent should be the approved array schedule or equivalent design summary, including the equipment configuration and units used by your organization.

Invalidate these fields when modules are added, removed, moved into or out of the approved scope, replaced with a different rated product, or split among scenarios. A placement-only change may leave the count and capacity unchanged, but it still requires revalidation because the approved parent changed. Do not prove currency by observing that the old and new numbers happen to match.

The stale symptom is often a locally edited headline. The design summary reflects the current array while a sales-written cover statement retains an earlier value. Another version appears in an offset chart, perhaps because that chart was exported before the latest design was accepted. Unit labels can also drift, leaving an apparently matching number with a different meaning or rounding policy.

The design owner confirms the approved module schedule. The proposal owner then compares every visible capacity and count occurrence, including alt text or captions that may be reused in customer communications. If rounding is permitted, retain the exact parent value and the display rule. Return mismatches to design when the parent itself is uncertain, and to proposal operations when the parent is clear but the dependent copy is wrong. Release only after all occurrences match the approved parent or an approved display transformation.

The U.S. Department of Energy’s PV system design overview explains that modules are only one part of a complete photovoltaic system and separately describes mounting structures, inverters, storage, and other components. That public overview supports keeping capacity separate from the rest of the equipment and scope record. It does not determine any project’s configuration.

3. Equipment names, models, and quantities

Equipment fields include manufacturer and model names, module family, inverter or power-electronics selection, storage equipment when applicable, mounting descriptions, quantities, and proposal-level equipment notes. They can appear in a design schedule, proposal summary, specification page, warranty section, scope, and customer email.

The controlling parent is the approved equipment schedule or bill-of-materials source designated by the project workflow. Invalidate proposal equipment fields whenever the product, model, quantity, pairing, option, or availability decision changes. A module swap that preserves capacity still invalidates model names and may invalidate quantity, layout, production, pricing, warranty language, and narrative comparisons.

Common stale symptoms include the new model in the equipment table but the old manufacturer in a paragraph, a product image that no longer represents the selection, a singular item description paired with a plural quantity, or a removed storage option still named in the benefits section. Treat marketing copy and captions as dependencies, not decoration.

The equipment or procurement owner confirms the current selectable record; design confirms what the approved scenario actually uses; estimating confirms the commercial scope; proposal operations reconciles the customer-facing result. Those roles may differ by organization. Return the proposal when the source systems disagree, the model is only provisional, or a quantity cannot be tied to the approved design. Do not let the proposal team infer technical compatibility, availability, warranty, or substitutability from an old template.

Release only when names, model identifiers, quantities, images, scope descriptions, and any equipment-specific narrative agree with the approved project records. If the commercial agreement permits an equivalent substitution, use the reviewed contract language and responsible approval. Do not invent a broad substitution promise to make the proposal appear flexible.

4. Layout image and placement description

The layout group includes the main array image, roof-plane or ground-area view, module placement, orientation labels, obstruction context, image captions, and prose describing where the system will be installed. It is easy to replace the hero image while leaving a thumbnail, appendix, annotated screenshot, or paragraph from the previous design.

The controlling parent is the approved layout view for the named scenario, including its model revision and export settings. Invalidate the group whenever modules move, orientation changes, an array area is added or removed, a different viewpoint becomes necessary, or the underlying roof or site model changes. Cropping and annotation changes also require review because they can hide or mislabel context.

The stale symptom is visual contradiction. A caption says “south roof” while the current image depicts a different approved area. A proposal summary states that modules are on two roof sections, but the refreshed image shows one. An older image may display a retired equipment footprint even when the count text is current.

The layout owner compares the proposal image against the approved design view, then checks captions and placement sentences as narrative dependencies. Return the artifact if the viewpoint cannot be tied to the approved scenario, if annotations obscure the change, or if a customer-facing description goes beyond what the design record establishes. Release only after the image, labels, caption, and prose describe the same configuration.

This field-level check does not reconcile an electrical single-line diagram. When a changed layout may affect electrical records, use the dedicated layout-to-SLD reconciliation guide and route decisions to the responsible electrical reviewer. A proposal image is not evidence that electrical design, code, utility, permitting, or construction requirements are satisfied.

5. Production estimate, losses, and model scenario

The production group includes annual or period output, offset, yield summaries, shading or solar-access summaries, loss assumptions, weather source labels, model scenario name, and explanatory text about expected generation. These are derived fields. Replacing a visible number without rerunning or confirming its inputs leaves the chain unverified.

The controlling parent is the accepted production-model run for the approved design scenario, not a number copied from the earlier proposal. Invalidate this group when placement, tilt, azimuth, module or inverter selection, capacity, shading inputs, loss assumptions, weather source, model configuration, or consumption mapping changes. Some inputs may not change the displayed rounded result, but the run still needs current provenance.

Sandia’s PV Performance Modeling Collaborative describes array orientation as an important performance-model input and distinguishes fixed and tracked orientation. Its plane-of-array irradiance guidance describes relationships among solar position, array orientation, irradiance components, ground reflection, and shading-related inputs. These sources support the dependency logic. They do not validate a project’s inputs, production estimate, or model accuracy.

Common symptoms include a refreshed annual total beside an old monthly chart, an offset percentage calculated against a different consumption record, a shading sentence that describes a removed obstruction treatment, or a loss summary attached to a previous model run. Another clue is a production page with no scenario or run identifier.

The modeling owner confirms the current run and its accepted inputs. Proposal operations compares every displayed output, chart, caption, and production narrative with that run. Return the proposal when the design revision and model run cannot be joined, an input is provisional, or two sections show different results. Release only when the current scenario and its limitations are identifiable and all dependent displays come from that accepted run.

6. Scope, quantities, pricing basis, adders, and exclusions

This group joins technical change with commercial interpretation. It includes the written scope, materials-related quantities, pricing basis, line items, adders, allowances, options, exclusions, and notes about work included or omitted. The controlling parent is usually not one document. It is the approved estimate or commercial scope record that consumes the accepted design and the organization’s current commercial decisions.

Invalidate the group when equipment, quantity, placement, access assumption, storage option, service work, roof work, trench or route assumption, project boundary, or customer-selected option changes. Also invalidate it when the design changes but the estimator concludes that price remains unchanged. That conclusion needs a current review record; silence is not proof that the old price remains valid.

The stale symptom is an internally consistent price built on an obsolete scope. A revised layout removes an array area, yet the scope still references work there. A new equipment choice appears in the specification page while the pricing basis describes the earlier selection. An adder is removed from the total but remains in the narrative, or an exclusion survives after the related work becomes included.

The design owner should identify what changed, but estimating or commercial leadership must decide the pricing treatment. Proposal operations should not guess whether a design change is cost-neutral. Compare quantities and scope dependencies with the approved design, then compare the commercial fields with the accepted estimate. Return unresolved differences to their owners. Release only when the scope, price, adders, options, exclusions, and assumptions describe one commercial scenario.

The U.S. Federal Trade Commission’s advertising guidance says advertising claims should be truthful, non-deceptive, and supported, including express and implied claims. That is U.S. business guidance, not legal approval of a solar proposal. It reinforces a practical review rule: do not let stale scope or pricing text imply something the current project record does not support.

7. Savings, payback, offset, financing, and narrative summary

Financial outputs often sit farthest downstream, so they can preserve several stale parents at once. This group includes savings, payback, bill comparison, offset, cash-flow or financing outputs, payment labels, incentive assumptions, and prose that summarizes affordability or value. The exact fields vary by organization and market.

The controlling parent is the approved financial scenario linked to the current production result, consumption or tariff inputs, commercial price, financing inputs, incentives where applicable, and other disclosed assumptions. Invalidate it when any linked design, production, price, consumption, rate, term, incentive, or scenario input changes. Time-sensitive financial and incentive content also needs its own current review.

Common symptoms include updated charts beside an old headline, a payback sentence copied from another option, a payment label that no longer matches the selected financing scenario, or an offset claim based on the earlier capacity. Narrative can be especially deceptive because it may avoid numbers while still implying the old result. “The revised design preserves the same economics” is a claim that requires support, not a harmless transition sentence.

The financial-model owner confirms inputs, method, output, date, jurisdictional context, and limitations. Proposal operations compares all charts, summaries, captions, callouts, and nearby sales language. Legal or compliance review may be required under the organization’s policies and market. Return the proposal when a source is missing, a time-sensitive input is unverified, or the narrative cannot be traced to the displayed result.

Release only after the financial scenario is joined to the current design, production, and price records and the customer-facing explanation states material assumptions and limits according to the approved policy. No field-level audit can guarantee savings, payback, financing availability, incentive eligibility, or future rates.

How should each proposal field be traced to its parent?

Trace each proposal field by recording its exact location, dependency type, controlling parent, parent revision, invalidation trigger, responsible owner, and comparison method. Then record whether it matched, was regenerated, was deliberately unchanged after review, or was returned. Do not accept a recent export date as a substitute for parent-level provenance.

Use this sequence after the design team announces an approved change:

1. Freeze customer release. Mark the current proposal as superseded or under revision so it cannot be sent while dependencies are unresolved.
2. Name the approved design revision. Record the scenario ID, revision, status, approving role, and the exact design artifacts accepted for downstream use.
3. Describe the delta. State what changed in plain language and which earlier assumptions or outputs may no longer be safe to reuse.
4. Open the seven-field register. List every customer-facing location for each applicable field, including cover copy, charts, captions, appendices, attachments, and saved email text.
5. Assign controlling parents. Name the source record and revision for each direct field, each derived calculation, and each narrative dependency.
6. Invalidate before comparing. Treat the previous dependent field as untrusted until its owner verifies or regenerates it. This prevents a plausible match from being accepted by habit.
7. Run owner reviews. Design checks design facts, modeling checks production, estimating checks commercial scope and price, finance checks financial outputs, and proposal operations reconciles the assembled artifact.
8. Compare the rendered proposal. Review the actual customer-facing output, not only source-system screens. Check repeated values, images, charts, captions, tables, headers, footers, and narrative.
9. Resolve or return every exception. Record the mismatch, affected page, controlling owner, decision required, and release impact. Do not close an exception with “updated” alone.
10. Authorize one release candidate. A named release owner confirms that every applicable field has a current parent and disposition, then records the version delivered to the customer.

The following matrix turns those steps into a compact assignment:

Copy-ready stale-field audit register

Copy this register into the project record and create one line for every customer-facing occurrence, not merely one line per category:

1. Project and customer record:
2. Proposal release-candidate ID:
3. Approved design scenario and revision:
4. Design approval status, owner, and date:
5. Field group:
6. Exact proposal page, block, chart, caption, or attachment:
7. Displayed field or narrative text:
8. Dependency type: direct, derived, or narrative:
9. Controlling parent record:
10. Parent revision, scenario, and status:
11. Invalidation trigger:
12. Responsible field owner:
13. Comparison or recalculation method:
14. Result: match, regenerated, revalidated, conflict, unresolved, or not applicable:
15. Evidence link or output ID:
16. Assumption or limitation that must remain visible:
17. Exception owner and required decision:
18. Disposition and reviewer:
19. Release or return rule:
20. Customer-delivered version and delivery record:

The register intentionally separates “revalidated” from “match.” A match says two visible values agree. Revalidation says the owner confirmed the value against the current parent and method. A regenerated output may still fail if it drew from the wrong scenario. Those statuses answer different review questions.

Illustrative example, not a customer case

Suppose a proposal team receives design revision REV-B. The accepted change moves an array from one roof area to another while retaining the approved module schedule. The proposal coordinator invalidates all seven field groups because the new revision could affect each parent, even though the capacity may remain unchanged.

Design revalidates capacity and module count against the REV-B array schedule. The layout owner replaces the image and placement caption. The modeling owner runs the production workflow from the approved geometry and labels the accepted result with the same scenario. Estimating records whether the changed placement affects scope, quantities, assumptions, adders, or price. The financial owner then uses the accepted production and commercial records to review downstream outputs.

During the rendered comparison, the coordinator finds that the main image and production chart are current but the executive-summary paragraph still says the modules occupy the earlier roof area. That paragraph is a narrative dependency. Its numbers do not need to be wrong for the proposal to be stale. The proposal returns to its narrative owner, the corrected paragraph is compared with the current layout, and the register records the disposition.

The example does not show that the change preserves production, price, savings, approval, or any customer result. It shows why an unchanged direct field, a regenerated derived field, and a rewritten narrative need separate checks.

What must pass before the revised proposal is released?

Release the revised proposal only when one approved scenario controls the artifact; all seven applicable field groups have current parents and dispositions; repeated values and narratives agree; unresolved items are returned to named owners; assumptions and limitations remain visible; and the exact rendered version, approval record, and customer-delivery record are linked.

A pre-release check should inspect the rendered proposal in reading order. Source-system parity is necessary, but customers see the export. A stale footer, flattened chart, image caption, appendix, or saved attachment can survive even when every live screen is correct.

Ask the release owner to verify these conditions:

• The cover, filename, footer, scenario labels, approval status, and issue date identify one release candidate.
• Every count, capacity value, product name, model, quantity, and placement statement matches its approved parent.
• The layout image, annotations, caption, and nearby prose describe the same configuration.
• Production totals, charts, shading or loss summaries, offset fields, and narrative use the accepted model scenario.
• Scope, quantities, price, adders, options, inclusions, exclusions, and assumptions describe one accepted commercial record.
• Financial outputs and explanatory language trace to current production, price, and financial inputs.
• Every deliberately unchanged field has a recorded revalidation, not an assumption that no change was needed.
• Every exception has an owner, decision, and release consequence. Nothing material is hidden in a blank cell.
• The version approved is the version delivered, and the delivery record can identify it later.

The release owner is checking controlled consistency, not issuing engineering, code, utility, permitting, legal, financing, or performance approval. An electrical change must follow the electrical review path. A pricing or advertising statement may need commercial, legal, or compliance review. A time-sensitive incentive or financing input needs current authoritative support for its jurisdiction and date.

SurgePV’s proposal workflow supports 3D roof modeling, solar array layout, shading analysis, energy-yield and financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. Those functions can help teams keep related work in a connected environment. Results still depend on source data, assumptions, equipment models, configuration, review, and responsible approval. The software does not guarantee field verification, automatic consistency, engineering conclusions, code or utility acceptance, financial outcomes, or error-free release.

The broader proposal-revision mistakes guide covers other ways customer-facing answers diverge. For this audit, the stopping rule is simpler: if a reviewer cannot identify the current parent and disposition for an affected field, the proposal is not ready to send.

Frequently Asked Questions

What makes a solar proposal field stale?

A field is stale when its displayed value still comes from an earlier design state, assumption set, source record, or manual narrative. It may look reasonable and be formatted correctly, yet no longer agree with the approved parent. The remedy is to trace it, compare it, and record a release decision.

Should every proposal be rebuilt after any design change?

Not necessarily. First classify the change and identify which proposal dependencies it invalidates. A wording correction may not require new production modeling, while a placement, capacity, equipment, or assumption change may affect several derived fields. Your release policy should determine whether to regenerate the full proposal or only controlled sections.

Who owns the final stale-field check?

Assign one release owner who confirms that each affected field has a parent, a comparison result, and an accepted disposition. Design, modeling, estimating, finance, and sales may each review their own fields, but a single named person should decide whether the customer-facing proposal is ready to leave the controlled workflow.

Does an unchanged number prove the proposal is current?

No. A value can remain numerically unchanged after recalculation and still need a new provenance record. The reviewer should confirm that it was derived from the approved revision and current assumptions, not merely copied from the earlier proposal. Matching values are evidence of parity only when their source and method are also current.

Can solar software guarantee that every proposal field is current?

No. Software can connect design, layout, shading, energy-yield, financial, electrical-workflow, materials, and proposal records, but results still depend on source data, assumptions, equipment models, configuration, review, and approval. Teams remain responsible for defining controlling parents, resolving exceptions, verifying customer-facing content, and obtaining qualified decisions where required.