Turn Irradiance and Loss Analysis Into Buyer Content

A marketer receives two polished exports: a colored irradiance map and a loss waterfall. The brief says, “Make this simple for buyers.” Nobody included the weather dataset, surface definition, model version, loss boundaries, or the proposal revision that produced the images. Simplicity now has an awkward job. It is being asked to hide the missing analysis packet.

To turn irradiance and loss analysis into buyer-friendly content, preserve the chain before simplifying the language. The content should show what solar resource was modeled, how it reached the proposed array plane, where named effects entered the model, what output the analysis supports, and which assumptions or changes could alter it. Friendly means usable, not detached from evidence.

For related tasks, use the customer irradiance walkthrough for a sales conversation, the loss-factor documentation guide for technical definitions, and the buyer-friendly proposal visuals guide for proposal presentation.

This guide covers the analyst-to-marketer handoff: organizing source records, mapping claims to evidence, briefing accessible visuals, obtaining technical review, and updating or withdrawing content when the analysis changes.

What must an analyst hand to the content team?

An analyst should hand the content team a reviewed source packet containing the reader decision, project or illustrative scope, run identifier, model and version, source datasets, location and time basis, geometry, units, irradiance definitions, loss mechanisms and boundaries, defaults, outputs, limitations, technical owner, approval state, and the events that make the packet stale.

The packet is not a screenshot folder. It is a release record. A screenshot can show what an interface displayed, but it may omit data lineage, hidden settings, exclusions, or whether the run was preliminary. Content should not inherit more authority than the analysis had.

Sandia’s PV Performance Modeling Collaborative guide organizes performance work from weather and design inputs through plane-of-array irradiance, module and inverter behavior, and system output. That general chain is useful for source-packet structure. It does not validate a private model, input, loss value, or result.

Use a source packet that separates four evidence states:

Do not upgrade one state into another during editing. A modeled value is not measured because a chart looks precise. A planning default is not a site fact because it appears in an analyst’s export. A sourced regional dataset is not proof of one roof’s future condition.

Build the release packet around a stable scenario

Assign one scenario identifier across analysis, claims, visuals, captions, article copy, proposal modules, and review comments. The identifier should connect the site or illustrative record, design revision, weather source, model configuration, loss set, output boundary, and release status.

NASA describes configuration management as visibility into and control of changes to functional and physical characteristics across a product life cycle. A solar content packet is not a NASA program. The useful analogy is version control: when the analysis changes, every derived graphic and statement must be discoverable.

Digital.gov’s plain-language guidance emphasizes creating and testing content for the intended audience. Plain language can improve labels and explanations. It cannot repair missing source identity or decide which technical qualification may be removed.

How do you explain irradiance without flattening the model?

Explain irradiance as the solar power arriving on a named surface at a particular moment, then distinguish accumulated solar energy and modeled electrical output. Show the chain from resource data through sun position, array orientation, shading, and plane-of-array treatment before discussing system conversion. Keep the dataset, location, period, units, and scenario visible.

The Department of Energy’s solar radiation basics says solar radiation at a location varies with geography, time of day, season, local terrain, and local weather. That is a strong reason to name source and scope. It does not validate a private dataset, site model, graphic, or production estimate.

Sandia PVPMC distinguishes irradiance and insolation. Irradiance describes power per area, while accumulated solar energy uses an energy-per-area basis over time. A marketer should not use “sunlight,” “solar resource,” “irradiance,” “irradiation,” and “production” as interchangeable decorative synonyms.

Use a four-part explanation:

1. Name the resource question. Is the reader comparing locations, seasons, roof planes, array areas, or scenarios?

2. Name the surface and time basis. State whether the graphic shows a horizontal, direct-normal, array-plane, instantaneous, interval, monthly, annual, representative, or other defined view.

3. Show the transformation. Connect source data to sun position, orientation, terrain or horizon, nearby shading, and the chosen transposition or model treatment.

4. Separate system output. Explain that equipment, temperature, electrical conversion, losses, availability, curtailment, and operating assumptions enter after or alongside the resource treatment, depending on the model.

Use one graphic for one irradiance question

A map is useful for spatial comparison. A monthly chart is useful for a time pattern. A sun-path view can explain geometry. A roof-plane table can normalize scenario inputs. A model-chain diagram can explain why irradiance is not final energy.

Do not combine every view into a single buyer panel. The colorful result becomes harder to question when the legend, period, surface, and scenario compete for space. Choose the smallest visual that makes the named relationship inspectable.

Sandia’s plane-of-array irradiance guidance describes beam, diffuse, and ground-reflected components in the modeled array-plane resource. That general structure prevents a direct-shadow picture from being presented as the whole resource model. It does not validate a project value or one software implementation.

How do you explain loss analysis without double counting?

Explain solar losses by naming each physical or operating mechanism, the model boundary where it acts, its source and status, unit and denominator, excluded mechanisms, and interaction with other steps. Preserve the model’s native sequence. Do not add percentages, reverse efficiencies, group categories, or create a total unless an analyst validates the transformation and displayed result.

“Loss” sounds like one bucket. A performance model may apply effects to irradiance, effective irradiance, DC power, AC conversion, collection, availability, curtailment, or another defined boundary. Two percentages can use different denominators even when the interface formats them the same way.

Sandia PVPMC treats shading, soiling, and reflection as distinct mechanisms within performance modeling. That supports separate definitions and overlap controls. It does not supply a project value or prove that a given software configuration avoids double counting.

Turn the loss stack into a mechanism story

A buyer does not need every internal field on the first page. The content still needs to retain the analytical record behind any grouping. Group only after a technical reviewer confirms that the summary preserves the model’s boundaries and does not imply simple addition.

Avoid waterfall theater. A waterfall chart can be useful when each step maps to the approved model and the baseline and endpoint are clear. It becomes misleading when independent percentages are stacked as if they share a denominator or when an unexplained residual is renamed to make the endpoint match.

The symbolic content rule is:

Published loss summary = reviewed transformation of the approved loss ledger

That is not a calculation. It is a release boundary. If the marketer needs a combined category, total, percentage-point change, or reformatted efficiency, the analyst must provide or validate a CalculationSpec with sources, units, dimensions, formula, result, and assumptions.

How should teams turn analysis into buyer-friendly content?

Turn reviewed analysis into buyer-friendly content by naming the reader decision, freezing the source packet, mapping claims, choosing one explanatory structure, drafting visuals and text equivalents together, completing technical and editorial review, adapting the approved module without strengthening claims, and publishing with scenario identity, limitations, owner, and a withdrawal trigger.

1. Name the reader decision. Decide whether the content explains terminology, compares scenarios, shows a mechanism, addresses a recurring question, or prepares a buyer for technical review.

2. Freeze the source packet. Record analysis run, design revision, sources, settings, units, loss ledger, output boundary, status, technical owner, and expiry events.

3. Build the claim map. Copy every numeric, comparative, technical, performance, and status claim into a ledger with its source, exact approved wording, qualification, visual location, and reviewer.

4. Choose the story architecture. Use resource-to-output for mechanism, side-by-side fields for comparison, time series for seasonality, spatial views for roof relationships, and a bounded waterfall only for an approved sequential loss story.

5. Draft the visual and text equivalent together. Write title, question, chart or diagram, units, labels, caption, visible explanation, data table where needed, alt purpose, and limitations as one asset.

6. Run independent technical and editorial review. The analyst checks model fidelity and claims. The editor checks reader task, language, context, accessibility, and whether any qualification disappeared in the layout.

7. Adapt without claim drift. A proposal module, article graphic, landing-page excerpt, email image, and social crop may use different space. None may become stronger than the approved source module.

8. Release with withdrawal control. Publish scenario, version, approval date, owner, source links where appropriate, limitations, and the events that require correction, replacement, or removal.

Build a claim ledger before polishing the copy

The claim ledger should include statements inside legends, labels, tooltips, captions, image text, headings, metadata, FAQs, and CTA copy. A visual can make a stronger claim than the paragraph beside it. “Modeled scenario” in body text does not fix a chart title that says “Your annual production.”

Which content claims should technical reviewers hold?

Technical reviewers should hold content when the dataset, scenario, surface, period, unit, loss boundary, model version, or source cannot be reconstructed; when a default appears measured; when categories overlap; when a visual exceeds the reviewed output; when a project result becomes a general claim; or when production, savings, accuracy, performance, or approval language outruns evidence.

The hold list should be written before the asset reaches design. Otherwise, typography and deadlines create pressure to “just add a footnote” to a claim that needs new analysis.

W3C’s complex-image tutorial explains that complex images may need a short description plus a longer textual description carrying the essential information. This supports a visible explanation or data table for dense irradiance and loss graphics. It does not by itself prove full accessibility conformance.

The FTC’s advertising guidance says advertising must be truthful and non-deceptive and objective claims need evidence. That general U.S. guidance applies to the claim posture, not the solar model. It does not approve a private graphic, production estimate, comparison, savings statement, or campaign.

Audit the asset outside the article body

Export the final image or interactive state and review it alone. Check title, subtitle, axes, unit, legend, scale, baseline, endpoint, color, data labels, tooltip text, caption, alt purpose, nearby explanation, scenario status, and source. The asset must not depend on a distant paragraph to correct its meaning.

Then inspect every crop. Social platforms, email tools, proposal builders, and content management systems may remove captions or shrink legends. If a safe crop cannot retain the necessary context, publish a different module rather than a stripped graphic.

Copy-ready irradiance and loss content record

Use this copy-ready record for one source module and every channel adaptation derived from it.

Illustrative workflow: the loss waterfall arrives without its ledger

This is an illustrative workflow, not a customer case or technical result. A content team receives an irradiance roof graphic and a loss waterfall for two illustrative array options. The colors and labels are polished, but the resource period is missing, the surface is unnamed, shading appears in two categories, and the loss endpoint does not identify its energy boundary.

The editor does not write around the gaps. The asset enters a technical hold. The analyst supplies the source dataset, scenario identifier, array-plane definition, model sequence, loss dictionary, overlap correction, output boundary, and approved explanatory claim. The content team then creates a normalized option table, a resource-to-output chain, and a smaller loss-mechanism graphic.

The final module labels the examples as illustrative, keeps both options on the same analytical basis, provides a visible text explanation, and lists the events that require rerunning the analysis. It claims no customer outcome, accuracy, future generation, savings, performance, approval, or conversion result.

Where SurgePV fits, and where it stops

SurgePV’s repository-verified scope includes solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. These functions can provide inputs and outputs for a controlled content source packet when responsible people verify the scenario and approve its customer-facing use.

SurgePV does not replace weather-source selection, site verification, engineering, manufacturer requirements, independent model validation, accessibility testing, advertising review, finance, tax, contract, utility, permitting, or other external authority. A polished output is not self-approving content.

The handoff should stay explicit. Analysts own model definitions, inputs, loss treatment, outputs, and technical limits. Content teams own reader structure, language, format, accessibility, and channel consistency. Qualified reviewers own customer claims and regulated or authority-sensitive conclusions. The shadow analysis workflow and generation and financial modeling tools can support the relevant technical work without changing those responsibilities.

Frequently Asked Questions

What is the simplest accurate way to explain solar irradiance?

Explain solar irradiance as the rate of solar power arriving on a surface at a particular moment, then name the surface and time basis. Distinguish it from solar energy accumulated over a period and from modeled system output. Location, orientation, weather data, shading, equipment, and loss assumptions connect the resource to the estimate.

Should buyer content show every solar loss percentage?

Show only loss information that supports the reader’s question and that a technical reviewer can reconstruct. Keep mechanism, model boundary, source, status, unit, denominator, exclusions, and overlap controls available. A concise grouped view may help, but it must not hide double counting, defaults, uncertainty, or a material loss behind a catch-all category.

Can a marketer add solar loss percentages together?

Not without the approved model or CalculationSpec. Losses may act at different stages, use different denominators, interact, or already be calculated inside another model step. Preserve the native definitions and order. If the publication needs a derived total or reformatted value, have the responsible analyst validate the formula, units, inputs, and displayed result.

What makes an irradiance or loss visual buyer-friendly?

A buyer-friendly visual answers one named question, labels the scenario, source, date, unit, model boundary, and status, and explains what could change. It uses readable axes, legends, patterns, and a visible text equivalent. It does not convert a model into a guarantee, conceal missing evidence, or rely on color alone.

Where can SurgePV support this content workflow?

SurgePV can support solar layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. A content team can use reviewed outputs as source material. Responsible analysts and reviewers must still verify inputs, model settings, loss treatment, claims, accessibility, finance context, engineering conclusions, and customer-facing release.

Buyer-friendly solar content should make the model easier to question. When the reader can see the resource basis, transformation, loss boundaries, scenario status, and next verification step, the explanation becomes simpler without pretending the analysis is more certain than it is.