Single Design-to-Proposal Revision Workflow

The revised layout removes a roof plane. The proposal still shows the earlier module pattern and the earlier customer-facing scenario. Both files carry a recent timestamp, both look finished, and each is current inside the folder where its owner works. Together, they describe different projects.

A single design-to-proposal revision workflow helps control that split by giving the change one governed identity from request to closure. The design, models, proposal, review notes, customer communication, and distribution receipt remain separate artifacts, but they all point to the same revision object and accepted source state.

Use this guide for the end-to-end revision record. Use the detailed solar design revision impact checklist, the material-change, technical design-versioning and field drawing guides for their specialist checks. This guide shows how a team moves one authorized change across those specialties and knows when the successor has actually replaced the prior release.

What is a single design-to-proposal revision workflow?

A single design-to-proposal revision workflow is a governed state machine in which one authorized change receives a stable revision id, a frozen starting baseline, named owners, recorded impact dispositions, matched successor artifacts, release approvals, distribution receipts, and closure evidence. It connects decisions without pretending that one file or software export controls every technical and commercial field.

The central object is the revision, not the document. A drawing can have its own revision number. A performance model can have a run id. A proposal can have a version. Those identifiers describe their artifacts. The shared revision id explains why they changed together and which accepted decision they represent.

NASA’s configuration-management reference describes making product state known, distinguishing versions, controlling baseline changes, tracking changes, and keeping products consistent with information about them. NASA does not prescribe a solar workflow. The process analogy is useful because a proposal should remain consistent with the project state it communicates.

Define the workflow in terms of states rather than inbox activity:

Avoid one generic status called updated. It cannot tell a proposal owner whether the design decision is still being evaluated, whether new production has been modeled, whether a price owner approved a commercial change, or whether an old customer PDF is still active.

What belongs in the shared revision object?

The shared revision object should contain the request, trigger, requester, authority, frozen design and proposal baseline, exact proposed difference, reason, affected project option, impact matrix, source evidence, decisions, owners, successor artifact ids, review gates, customer communication, recipients, withdrawal actions, open conditions, closure rule, and immutable history of state changes.

Freeze the baseline before editing. Record the controlling design id and revision, model run or scenario, equipment basis, proposal id and issue purpose, commercial assumptions, customer state, and every known downstream artifact. A revision with no starting point cannot prove what changed. It can only show what exists now.

The proposed difference needs more than a sentence saying “update design.” Name the object, old state, proposed state, trigger, evidence, requested purpose, and authority needed. If a site survey found an obstruction, retain the observation and which geometry it affects. If equipment availability triggered a proposed substitution, retain the exact proposed item and treat acceptance as a separate decision.

NASA’s requirements-management reference describes bidirectional traceability and evaluating proposed baseline changes for effects across cost, schedule, architecture, design, interfaces, operations concepts, and related requirements. That is a systems-engineering context, not a solar rule. It supports keeping the change linked both backward to its basis and forward to affected consumers.

Use one record with explicit field ownership:

Keep decision authority beside the field. Design, performance, electrical, equipment, finance, price, contract, customer communication, and release ownership can sit with different people. A shared record coordinates their decisions without collapsing them into one approver.

How should a design change become a revised proposal?

Move the change through twelve steps: open one revision id, preserve the trigger, freeze the active baseline, classify authority and urgency, define the exact difference, screen every consumer, obtain missing dispositions, update controlled sources, regenerate affected outputs, compare the successor set, approve and distribute one bounded release, then close after withdrawal and receipt evidence is complete.

1. Open the revision object. Assign a stable id, project and option, requester, trigger time, proposed purpose, and initial owner. Link the original request instead of paraphrasing away its meaning.
2. Preserve the trigger evidence. Store the survey note, customer instruction, technical finding, equipment notice, correction, or other basis with its source and limits. Do not convert an observation into an accepted change yet.
3. Freeze the current baseline. Record design, layout, model, equipment, electrical, materials, financial, proposal, contract-facing, and distribution versions that may matter. Prevent silent edits while the baseline is being established.
4. Classify authority and urgency. Identify who can evaluate, authorize, implement, review, communicate, and release the change. State which uses must pause before a final disposition.
5. Define the exact proposed difference. Record old state, proposed state, object, reason, evidence, and acceptance criteria. Separate a requested outcome from the technical method used to reach it.
6. Screen all potential consumers. Route the change through design, production, financial, equipment, electrical, materials, price, scope, proposal visuals, assumptions, customer documents, permitting, utility, procurement, schedule, and construction areas that apply.
7. Resolve or bound each impact. Require reviewed impact, reviewed no impact, unknown, not applicable, or hold. Name the owner, evidence, due condition, affected uses, and disposition date.
8. Update controlled source records. Apply the accepted change where each field is governed. Do not patch a proposal number if the design or model source should control it.
9. Regenerate affected artifacts. Produce successor layout, model, equipment, electrical, materials, financial, proposal, or other outputs from the accepted basis. Preserve deliberate manual edits as traceable exceptions.
10. Run the successor comparison. Compare old and new artifacts with the authorized difference and impact register. Find accidental changes, missed changes, stale assumptions, mismatched identifiers, and hidden holds.
11. Approve and distribute the release. Record the reviewers, purpose, limitations, customer communication, recipients, successor ids, and withdrawal instructions for superseded copies.
12. Close on evidence. Confirm implementation or rejection, impact dispositions, artifact parity, approvals, receipts, withdrawals, open-condition ownership, customer record, and current-version registration.

The workflow should return to assessment when a new material fact appears. It should not open an unrelated revision id merely because the first request became more complicated. Keep one chain until the scope truly splits into independent decisions or project options.

The solar design revision management guide owns technical versioning conventions and the wider project lifecycle. This workflow uses those artifact versions as evidence inside the shared revision. A proposal version should not replace the design revision scheme, and a design revision should not pretend to record customer distribution.

How should impact, no-impact, and unknown decisions be recorded?

For every applicable area, record one of five states: reviewed impact, reviewed no impact, unknown, hold, or not applicable. Each state needs an owner, evidence, affected artifacts, use restriction, and dated disposition. A blank is not a no-impact decision. Copying the old value is not evidence that the change left it untouched.

Use the detailed revision impact checklist when the change can affect production, financials, or proposal claims. The present workflow asks whether that review happened, what it decided, and which successor consumes the decision. It does not reperform every model or commercial check.

Solar design fields are connected. The Department of Energy describes PV system design through modules, mounting, orientation, inverters, storage, and other balance-of-system technologies. That general system context supports screening relationships instead of treating a layout edit as isolated. It does not decide a private design or revision.

Performance also depends on an input chain. Sandia PVPMC’s modeling guide describes a process beginning with weather, irradiance, module, and system-design inputs and proceeding through intermediate models to system output power. A changed design input may therefore require a performance-model disposition. The citation does not prove that any particular change alters a result.

Record the impact decision with a short, testable basis:

Avoid broad no-impact statements. “No proposal impact” can hide distinct conclusions about visuals, production, financial assumptions, price, scope, schedule, equipment, customer promises, and contract-facing language. A reviewer may accept no impact for some fields and leave others unknown.

Solar resource adds another dependency. DOE says solar radiation at a location varies with geography, time of day, season, local landscape, and local weather. Keep location and resource context stable when comparing revised modeled output. The statement does not validate a dataset, loss assumption, or project result.

If a change arrives after customer review, consider communication state separately from technical state. A technically accepted revision may still need explanation, renewed acknowledgement, updated terms, or another organization-specific action. Route that decision to the people responsible for the customer and contract rather than hiding it in a design note.

Which gates should a revised proposal pass before release?

A revised proposal should pass identity, authority, baseline, impact, source, regeneration, cross-artifact consistency, claim-support, disclosure, customer-change, approval, and distribution gates. Every gate must name its reviewer and release purpose. A clean export, recent timestamp, valid calculation run, or approved design cannot by itself authorize customer-facing release.

Start with the authorized difference. The successor should contain the intended change and avoid unrelated drift. Compare all material customer-visible and governed fields against the baseline. A revision that fixes module count while silently changing financing assumptions is two changes pretending to be one.

Run these gates:

The eight checks across layout, equipment list, and SLD can support the consistency gate when those artifacts are in scope. The SLD approval workflow owns electrical-document routing. This revision record coordinates their results without claiming to perform electrical review.

Customer-facing statements need special care. The FTC’s United States small-business advertising guide says advertising must be truthful and non-deceptive and that advertisers need evidence to support claims. This is United States federal context, not legal advice. Use qualified legal and compliance review appropriate to the market and proposal.

Check visible assumptions, not only headline numbers. A revised layout image can imply finality while the production and price still belong to the prior design. The article on invisible proposal assumptions explains why polished presentation cannot substitute for a disclosed basis.

How should recipients, supersession, and closure be controlled?

Release the revised design and proposal with one issue receipt listing the revision id, successor artifacts, purpose, limitations, reviewers, recipients, and files replaced. Send explicit withdrawal or replacement instructions to prior recipients, record customer communication where applicable, preserve superseded versions, and close only after the current set is registered and unresolved conditions have owners.

Distribution is part of change control. A perfect successor in a private folder does not correct a proposal already emailed to a customer, a design shared with an installer, or an attachment copied into a CRM. The revision owner needs the prior recipient list and a way to record replacement, withdrawal, acknowledgement, or another applicable treatment.

Do not delete superseded files as a substitute for controlling them. Preserve their lineage and prevent ordinary active use. A superseded watermark, archive state, replacement notice, or access rule can help, but the organization needs a clear current-version register.

Field drawings need their own distribution controls. The solar construction drawing revision-control guide owns field release sheets, stale PDF prevention, and crew-facing change routes. A design-to-proposal revision may trigger that workflow, but customer proposal closure should not imply that construction recipients are resolved.

Use a release receipt:

Customer communication should state the material difference at the reader’s level. Do not dump an internal change log into a sales email. Explain what changed in the system or offer, why the revised information differs, which assumptions remain, and what decision or acknowledgement is requested. Preserve the communication in the revision record.

Close the revision when the evidence chain is complete, not when the proposal PDF exports. A revision can remain open after release if a bounded condition has a named owner and the release purpose permits it. State that clearly. Closure then records whether the condition was resolved, transferred, or triggered another revision.

Illustrative workflow: an accepted equipment and layout change

This is a visibly labelled illustrative workflow, not a customer case, product recommendation, equipment-equivalence decision, financial result, legal conclusion, or measured outcome. Assume a project team receives a proposed equipment change after an early layout and proposal already exist. The proposed item also changes the physical layout pattern. No technical acceptance has occurred.

The coordinator opens REV-EXAMPLE and freezes the current layout, equipment basis, performance scenario, proposal, customer communication, and recipients. The equipment notice is retained as the trigger. The proposal is not edited yet because availability does not prove technical equivalence, accepted selection, price treatment, or customer scope.

The responsible design, equipment, electrical, performance, financial, price, contract, and customer owners receive impact rows. Some fields may be not applicable. Some may receive reviewed no-impact dispositions. The layout, equipment, modeled production, visual, and customer description remain on hold until their owners complete the applicable work.

After the responsible people accept the project-specific change, the controlled equipment and design records are updated. A successor layout and any affected technical or modeled outputs are produced. The proposal owner regenerates the customer-facing version from the accepted basis, then checks that the equipment description, system representation, assumptions, production, financial information, price, scope, and visible limitations reflect the recorded dispositions.

The release gate finds that an old proposal screenshot remains in the CRM. The release owner replaces it, records the successor proposal id, and sends the applicable customer communication. The receipt lists the design, model, proposal, reviewers, recipients, and files replaced. Only then does the closure owner sign REV-EXAMPLE.

Nothing in the example determines whether the proposed equipment should be accepted or which technical and commercial fields must change. Its purpose is narrower: one change keeps one identity while qualified owners make separate decisions.

Copy-ready design-to-proposal revision record

Use the following as a ticket, worksheet, or project record. Adapt authority, legal, compliance, technical, contract, and customer fields to your organization and jurisdiction.

Revision identity and baseline

• Shared revision id:
• Project, site, building, and option:
• Requester and request time:
• Trigger and retained evidence:
• Proposed purpose and urgency:
• Baseline design id and revision:
• Baseline model run and assumptions:
• Baseline equipment and electrical basis:
• Baseline financial scenario:
• Baseline proposal id, purpose, and customer state:
• Prior recipients and active copies:

Proposed and authorized difference

• Object or field changing:
• Old state:
• Proposed state:
• Reason:
• Evidence and limitations:
• Evaluation authority:
• Implementation authority:
• Customer or contract authority:
• Accepted, rejected, conditioned, or still under assessment:

Impact register

Successor and review

• Updated controlled source fields:
• Successor layout or design:
• Successor equipment, electrical, or materials records:
• Successor model run and validated calculations:
• Successor financial scenario:
• Successor proposal:
• Authorized-difference comparison:
• Cross-artifact consistency outcome:
• Claim and assumption review:
• Technical reviewers:
• Commercial, legal, compliance, and customer reviewers:
• Release purpose and limitations:

Distribution and closure

• Release owner and time:
• Successor recipients:
• Superseded artifacts:
• Withdrawal or replacement action:
• Customer communication and acknowledgement:
• Open conditions, owners, and due conditions:
• Current-version register updated:
• Closure reviewer and date:
• Reopen triggers:

Retain superseded records and personal data according to the applicable contracts, legal requirements and organization’s approved retention schedule; this workflow does not prescribe indefinite retention. Record lawful disposition without losing required lineage.

The record should preserve history. Do not overwrite a rejected proposal change with the accepted one. Another reviewer needs to know what was requested, what changed during assessment, which version was implemented, and why prior copies were withdrawn.

Where SurgePV fits and where software stops

Evaluate the offered SurgePV configuration against the shared revision record and representative changed project. Record which sources, outputs and identifiers are available, what updates automatically, what requires manual handling and which history or export functions remain outside scope. This article does not independently verify native approvals, recipient receipts, automatic supersession or an immutable audit trail.

SurgePV’s solar proposal workflows can sit inside the shared revision process. Ask the vendor to demonstrate project identifiers, accepted-input reuse, affected-output regeneration, scenario retention and visible differences. Preserve separate controlled records wherever those functions are unavailable. It cannot decide equipment equivalence, authorize a technical or commercial change, interpret contracts or law, approve customer communication, confirm external acceptance, or prove that source evidence is current and correct.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs do not replace approval by the responsible engineer, authority, lender, insurer, utility, customer, legal or compliance reviewer, contract owner, or another accountable party. Commercial terms require the applicable written quote and review.

The useful product question is not whether software has a revision button. Ask whether a reviewer can trace the authorized change through design, model, proposal, approvals, recipients, and successor state without comparing mystery exports by hand.

Frequently Asked Questions

Does every solar design change require a revised proposal?

No universal rule makes every design change proposal-material or proposal-neutral. Screen the authorized change against customer-visible layout, equipment, modeled production, financial inputs, price, scope, assumptions, schedule, and contract-facing statements. Record reviewed impact, reviewed no impact, unknown, or hold for each applicable area, with the owner and supporting evidence.

Which file should control when the design and proposal disagree?

Neither file should win by age, filename, folder, or visual polish. Freeze the disagreement, identify the authorized change and current baseline, determine which governed source controls each disputed field, obtain the required technical or commercial disposition, correct the source record, then regenerate and review every affected consumer before issuing a successor.

Can a salesperson update only the proposal after a design change?

A proposal owner can correct customer-facing content within their authority, but should not independently invent a design, equipment, production, financial, price, or scope disposition. Route the change through the shared revision record, correct controlled inputs, regenerate affected outputs, and document any deliberate manual exception so the proposal and design do not split into competing project states.

What should happen when revision impact is unknown?

Keep the impact state unknown, name the missing evidence or authority, assign an owner, restrict every use that depends on the unresolved field, and state the condition that closes the issue. Do not copy the old value, assume no impact, or release a clean-looking proposal that hides the uncertainty in an internal note.

When is a design-to-proposal revision actually closed?

Close the revision after the authorized change is implemented or rejected, all applicable impact areas have dispositions, affected artifacts share the accepted basis, required reviewers approve the stated release, prior recipients receive replacement or withdrawal instructions, customer communication is recorded where needed, open conditions have owners, and the successor is registered as current.

The successor needs more than a new filename

A revision is complete when people can trust the relationship among the change, its evidence, the current design, and the current proposal. Recent timestamps help with sorting. They do not establish authority, impact review, customer communication, or replacement of prior copies.

Give the change one identity. Freeze the starting point. Let each qualified owner make the decision that belongs to them. Regenerate from controlled sources, compare the whole successor set, release it for a stated use, and collect the receipts that prove old copies were addressed.

The shared revision record then answers the question that folders cannot: why do these files belong together, and what exactly do they replace?