System Requirements Document for solar-radiation

1. Introduction

solar-radiation is a solar radiation calculator: a measurement instrument delivered as a web application. A user supplies the inputs that describe a site and a collector geometry, runs the calculation, and reads the resulting solar radiation values as an authoritative numeric output.

The product intent is precision, trust and clarity. The audience is the working practitioner who needs numbers they can defend in a client report — engineers, installers, agronomists and off-grid planners — rather than a lifestyle consumer. The interface is therefore built as an instrument face: a labelled input stack on a visible grid, a single oversized result figure, and a ruled breakdown table of radiation components.

The application is a first-party custom UI with two destinations: a public Landing page that states what the product is and how it works, and a Calculator workspace where the calculation is performed and the result is read. No account, sign-in, or stored profile is part of the accepted scope.

2. System Overview

solar-radiation is a browser-delivered web application. It consists of a public entry surface and a single cohesive calculator workspace. The user moves from the Landing page into the Calculator, enters the site and geometry inputs, triggers the calculation, and reads the resulting solar radiation values.

Actors

• Solar Radiation Calculator User — the sole active human role. A person who wants to compute solar radiation values for a site and geometry, and to read the resulting output.
• Calculation engine — a non-persona system actor owned by the application. It consumes the submitted inputs and produces the radiation values. It has no independent human interaction.

Accepted behavior

• The application computes solar radiation values from user-provided inputs.
• The application shows the computed result to the user.

Ownership

• Both destinations are application-owned custom pages.
• Both destinations are reachable without establishing an identity. No accepted journey requires durable actor-specific state, a stored history, a commitment bound to a participant, or a value transfer, so no application-owned identity is introduced.

Narrow exclusions

• No account creation, sign-in, profile, or saved-project management is in scope.
• No provider-owned or external destination is in scope.
• No future-horizon capability is claimed as current.

2a. Product Interpretation and Delivery Boundary

The product is delivered entirely as a first-party web application. There is no provider surface, no external destination, and no headless-only delivery path. Everything the user does — reading what the product is, entering inputs, running the calculation, and reading the result — happens inside the two application-owned pages.

Access is open. The Landing page is the anonymous first impression and is reachable by anyone. The Calculator is likewise reachable without establishing an identity, because the accepted behavior is a single self-contained computation whose inputs the user supplies in the moment and whose result the user reads in the moment. Nothing in the accepted scope requires the application to remember a user between visits, to bind a result to a returning participant, or to protect state from other participants. Introducing an account boundary would add a capability the source did not accept.

The current delivery horizon covers exactly two things: computing solar radiation values from user-provided inputs, and showing the result. Anything beyond that — saved sites, comparison across locations, export, historical archives, or third-party data feeds — is outside the current boundary and is not represented in any page, requirement, or flow.

2c. Page Content and Component Coverage

Landing

The public entry surface. It explains that the product is a solar radiation calculator, who it serves, and what it does, and it provides the way into the Calculator.

Information and state

• Product identity: the name solar-radiation and the headline Solar radiation, measured properly.
• A one-line statement of what the product does: it computes solar radiation values from inputs the user provides and shows the result.
• A statement of who it serves: engineers, installers, agronomists and off-grid planners who need defensible numbers.
• A schematic sun-path diagram: a quarter-circle arc, a panel plane, angle ticks, and micro-labels for tilt, azimuth and latitude.
• A strip of four colour-coded data chips reading like a transit departure board: GHI, DNI, DHI and temperature, each a white panel with a 4px coloured left border.
• A numbered three-step strip: 1 · LOCATION, 2 · GEOMETRY, 3 · RESULT, with red numerals and hairline vertical dividers.
• No user-specific state is held on this page.

Primary action

• Enter the Calculator.

Supporting actions

• Read the three-step explanation of how a calculation proceeds.
• Read the component colour code from the data chips and the sun-path diagram legend.

Domain entities

• Radiation component (Global Horizontal Irradiance, Direct Normal Irradiance, Diffuse Horizontal Irradiance).
• Solar geometry (sun path, panel plane, tilt, azimuth, latitude).

Component responsibilities

• Hero block — flush-left headline spanning the left columns, with a single red rule beneath it; the schematic sun-path diagram occupies the right columns.
• Data chip strip — four chips, each carrying a component label, a value with unit, and a colour-coded left border.
• Three-step strip — numbered steps with red numerals and hairline vertical dividers.
• Entry control — the single control that opens the Calculator.

States

• Loading — static content; no loading state is required.
• Empty — not applicable; the page has no user-supplied data.
• Success — the page renders fully and the entry control is available.
• Error — not applicable; there is no data operation on this page.
• Recovery — not applicable.

Calculator

The cohesive calculator workspace. The user enters calculation inputs, runs the calculation, and views the resulting solar radiation values.

Information and state

• The current value of every input field, held in the page's working state.
• The current validation state of each input field.
• The calculation state: idle, running, or complete.
• The computed result: a total radiation figure with its unit, plus a breakdown table of radiation components.
• The last submitted input set, retained so the user can adjust one value and recalculate.

Primary action

• Run the calculation from the currently entered inputs.

Supporting actions

• Edit any individual input value.
• Read the total result figure and its unit.
• Read the breakdown table of radiation components.
• Adjust an input and recalculate from the retained input set.

Domain entities

• Input set — Latitude, Longitude, Tilt, Azimuth, Date, Time, Cloud Cover.
• Result — total radiation figure with unit.
• Result breakdown rows — Direct Normal, Diffuse Horizontal, Global Horizontal, Extraterrestrial.

Component responsibilities

• Input stack — the left column of the instrument panel. Each input is a labelled row: an uppercase 12px label on the left, a right-aligned tabular value on the right, separated by a 1px hairline rule. Every field is named in type; no icon-only inputs.
• Calculate control — the primary action control, carrying the signal red treatment.
• Result figure — the oversized total radiation readout in red with tabular numerals and an uppercase unit label beneath it.
• Breakdown table — a ruled table of the four component rows, each with a colour-coded 4px left border: red for total radiation, yellow for beam, grey for diffuse.
• Validation messaging — per-field messages naming the field and the problem.

States

• Loading — the page shell renders immediately; the input stack and controls are present before any calculation.
• Empty — before the first calculation, the result region shows no figure and no breakdown rows; the input stack is fully available and the Calculate control is enabled once required inputs are present.
• Success — the total figure is displayed with its unit, and the breakdown table shows all four component rows.
• Error — when an input is missing, non-numeric, or outside its accepted range, the calculation does not run; the offending field is marked and a message naming that field is shown, and the previously displayed result, if any, is left intact rather than replaced with a partial figure.
• Recovery — the user corrects the marked field and runs the calculation again; the retained input set means only the corrected value needs re-entry.

3. Functional Requirements

FR-1 — Compute solar radiation values from user-provided inputs explicit As a Solar Radiation Calculator User, I should enter the inputs that describe my site and collector geometry and have the application compute the solar radiation values from them, so that I obtain a radiation figure derived from my own parameters.

• Trigger/input: the user submits the input set from the Calculator.
• Observable result: the application produces the solar radiation values for the submitted input set.
• Access state: the Calculator is reachable without establishing an identity.
• Failure/recovery: if the input set is incomplete or invalid, no values are produced and the offending field is named; the user corrects it and resubmits.
• Continuation: the produced values are available to be shown to the user.

FR-2 — Show the computed result to the user explicit As a Solar Radiation Calculator User, I should see the computed solar radiation result displayed after the calculation, so that I can read the value I asked for.

• Trigger/input: the completion of a calculation.
• Observable result: the total radiation figure is displayed with its unit, and the breakdown table shows the component rows.
• Access state: the Calculator is reachable without establishing an identity.
• Failure/recovery: if no calculation has completed, no figure is shown; the result region remains empty rather than displaying a placeholder number.
• Continuation: the user can adjust an input and recalculate.

FR-3 — Enter the site and geometry inputs required_inference As a Solar Radiation Calculator User, I should be able to enter Latitude, Longitude, Tilt, Azimuth, Date, Time and Cloud Cover as named, labelled fields, so that the calculation has the parameters it needs.

• Trigger/input: the user types or selects a value in a labelled input row.
• Observable result: the field holds the entered value, right-aligned with tabular numerals, and the input set reflects it.
• Access state: the Calculator is reachable without establishing an identity.
• Failure/recovery: a value that is missing, non-numeric, or outside its accepted range is marked and named; the user corrects it.
• Continuation: the corrected input set is ready to be submitted.
• Rationale: the accepted behavior is "computes solar radiation values from user-provided inputs"; inputs must therefore be enterable and named.

FR-4 — Read the breakdown of radiation components required_inference As a Solar Radiation Calculator User, I should see the result broken into Direct Normal, Diffuse Horizontal, Global Horizontal and Extraterrestrial rows alongside the total, so that I can see how the total is composed.

• Trigger/input: the completion of a calculation.
• Observable result: four ruled rows are displayed, each with its component label, its value with unit, and its colour-coded left border.
• Access state: the Calculator is reachable without establishing an identity.
• Failure/recovery: if no calculation has completed, no rows are shown.
• Continuation: the user reads the rows and may adjust an input to recalculate.
• Rationale: the accepted behavior is "shows the result to the user"; a radiation result is composed of these components, and the total alone would not be a usable result.

FR-5 — Recalculate after adjusting an input required_inference As a Solar Radiation Calculator User, I should be able to change one input and run the calculation again without re-entering the rest, so that I can compare outcomes across parameter changes.

• Trigger/input: the user edits a field in the retained input set and runs the calculation again.
• Observable result: the result figure and breakdown rows update to the values for the new input set.
• Access state: the Calculator is reachable without establishing an identity.
• Failure/recovery: if the edited value is invalid, the calculation does not run and the previous result remains displayed.
• Continuation: the user may continue adjusting and recalculating.
• Rationale: a calculator whose inputs cannot be varied after the first run would not support the accepted compute-and-show behavior as a usable lifecycle.

FR-6 — Learn what the product is and how a calculation proceeds required_inference As a Solar Radiation Calculator User, I should be able to read, before entering anything, what the product computes, who it is for, and the three steps a calculation follows, so that I know whether it serves my need.

• Trigger/input: the user opens the Landing page.
• Observable result: the headline, the product statement, the audience statement, the schematic sun-path diagram, the data chip strip, and the numbered three-step strip are displayed.
• Access state: anonymous; no identity is required.
• Failure/recovery: not applicable; the content is static.
• Continuation: the user enters the Calculator.
• Rationale: the Calculator is a first-party destination that must be reachable; an entry surface that states the product's purpose is the indispensable prerequisite for a user arriving without prior context.

FR-7 — Reach the Calculator from the Landing page required_inference As a Solar Radiation Calculator User, I should be able to move from the Landing page into the Calculator, so that I can begin a calculation.

• Trigger/input: the user activates the entry control on the Landing page.
• Observable result: the Calculator is displayed with its input stack and Calculate control available.
• Access state: no identity is required to enter.
• Failure/recovery: not applicable.
• Continuation: the user enters inputs.
• Rationale: the Calculator is a separately navigable destination; without a way to reach it the accepted compute-and-show behavior would be unreachable.

4. User Personas

Solar Radiation Calculator User

Product context. This person works with solar radiation figures as part of a professional or planning task. They arrive with a specific site and a specific collector geometry in mind, and they need a number they can put in front of someone else — a client, a colleague, a report. They are not browsing; they are measuring. They may arrive at the Landing page without prior knowledge of the product and need to confirm in a few seconds that it computes what they need, or they may arrive already knowing and go straight to the Calculator.

Primary goal. To obtain solar radiation values for a site and geometry they specify, and to read those values clearly enough to use them.

Distinct accepted responsibilities.

• Supplying the site and geometry parameters that describe the case being measured: Latitude, Longitude, Tilt, Azimuth, Date, Time and Cloud Cover.
• Deciding when the input set is complete enough to run.
• Running the calculation.
• Reading the total radiation figure and the component breakdown, and judging whether the result is the one they wanted.
• Adjusting a parameter and running the calculation again when they want a different case.

Relevant inputs and decisions.

• The numeric values for each input field, and the date and time of interest.
• The decision of whether the entered set is correct before running the calculation.
• The decision, on reading the result, of whether to accept it or change an input and recalculate.

Interactions with other accepted participants. There is no other accepted human participant. The only other actor is the application's calculation engine, which consumes the submitted input set and returns the radiation values. The user's interaction with it is entirely through the Calculate control and the result region.

Observable success. The total radiation figure is displayed with its unit, and the breakdown table shows the Direct Normal, Diffuse Horizontal, Global Horizontal and Extraterrestrial rows for the input set the user submitted.

What makes this role's work different. The role is defined by the act of specifying a case and reading a number back, not by managing an account, a project, or a history. Every session is self-contained: the inputs are supplied in the moment and the result is read in the moment. There is no state to resume, no record to curate, and no other participant to hand off to. The whole of the role's work is the loop between the input stack and the result figure.

5. Core User Flows

Flow 1 — Understand the product and enter the Calculator

1. The Solar Radiation Calculator User opens the application and lands on the Landing page. No identity is required.
2. The user reads the flush-left headline Solar radiation, measured properly and the statement of what the product computes and who it serves.
3. The user reads the schematic sun-path diagram — the red arc, the ink panel plane, the yellow angle ticks, and the micro-labels for tilt, azimuth and latitude — and the four colour-coded data chips for GHI, DNI, DHI and temperature, learning the component colour code.
4. The user reads the numbered three-step strip: 1 · LOCATION, 2 · GEOMETRY, 3 · RESULT.
5. The user activates the entry control and the Calculator page is displayed with its input stack and Calculate control available.
6. Continuation: the user proceeds to Flow 2.

Flow 2 — Compute solar radiation values for a site and geometry

1. The Solar Radiation Calculator User is on the Calculator page. The result region is empty: no figure and no breakdown rows are shown, because no calculation has run.
2. The user enters the site parameters in the labelled input rows: Latitude and Longitude. Each row shows an uppercase 12px label on the left and the entered value right-aligned with tabular numerals on the right, separated by a 1px hairline rule.
3. The user enters the collector geometry: Tilt and Azimuth.
4. The user enters the time parameters: Date, Time and Cloud Cover.
5. The user reviews the input stack, which now reads as a specification sheet of label/value pairs.
6. The user activates the Calculate control.
7. The application computes the solar radiation values from the submitted input set.
8. Observable result: the total radiation figure is displayed in red with tabular numerals and an uppercase unit label beneath it, and the breakdown table shows the Direct Normal, Diffuse Horizontal, Global Horizontal and Extraterrestrial rows, each with its value, unit and colour-coded left border — red for total, yellow for beam, grey for diffuse.
9. Continuation: the user reads the result and proceeds to Flow 3, or stops.

Flow 3 — Correct an invalid input and complete the calculation

1. The Solar Radiation Calculator User is on the Calculator page and activates Calculate.
2. One or more input fields are missing a value, non-numeric, or outside their accepted range.
3. Observable result: the calculation does not run. The offending field is marked and a message naming that field is shown. If a result was previously displayed, it remains displayed rather than being replaced with a partial or placeholder figure.
4. The user reads the message, identifies the named field, and corrects the value in that row.
5. The user activates Calculate again.
6. Observable result: the calculation runs on the corrected input set and the total figure and breakdown rows are displayed.
7. Continuation: the user reads the result, or proceeds to Flow 4.

Flow 4 — Adjust a parameter and recalculate

1. The Solar Radiation Calculator User has a completed result on the Calculator page, with the total figure and the four breakdown rows displayed.
2. The user decides to measure a different case — for example a different tilt, or a different date.
3. The user edits that single field in the retained input set. The other fields keep their values.
4. The user activates Calculate.
5. The application computes the solar radiation values for the new input set.
6. Observable result: the total figure and the breakdown rows update to the values for the new input set.
7. Continuation: the user may repeat steps 3–6 to compare further cases, or stop.

6. Visuals Colors and Theme

Muse and headline. Erik Spiekermann — typographic infrastructure for solar physics. The interface is a measurement instrument, not a marketing page: wayfinding through data, where inputs become outputs and every figure is legible at a glance.

Mode. Light mode.

Colour tokens

Proportions: approximately 60% paper ground, 25% white surfaces, 8% red, 5% yellow, 2% ink. No blue or indigo anywhere in the palette. The signal colours are red and mustard yellow only.

Typography

• Headings: Fira Sans — SemiBold (600) and Bold (700), set flush-left with tight tracking (-0.01em).
• Body: Fira Sans.
• Numeric readouts: Fira Sans with tabular figures enabled (font-variant-numeric: tabular-nums), so digits align in columns like a departure board.
• Labels: Fira Sans Medium (500), uppercase, 11–12px, 0.08em tracking.
• No display serif, no script. The type is the interface.
• Scale: 1.333 modular — 64 / 48 / 36 / 27 / 20 / 16 / 14 / 12.
• Mobile hero headline 40px, desktop 72px. Result figure 56px mobile to 96px desktop. Input labels 12px uppercase. Body 16px with 1.5 line-height. Data rows 14px with tabular numerals.

Shape language. Rectilinear and honest. 4px radii on inputs and buttons — touchable, never soft. 1px hairline rules (#D8D2C8) separate every data row; 2px rules mark section boundaries. Colour-coded 4px left borders on result cards act as transit-line markers: red for total radiation, yellow for beam, grey for diffuse. No shadows, no blur, no glass. The grid is visible and proud.

Spacing rhythm. A strict 12-column grid with 24px gutters and a 1200px maximum content width. The calculator is a two-column instrument panel: the left column (5 columns) holds the input stack in labelled rows; the right column (7 columns) holds the result — one oversized total figure in red, then a ruled breakdown table. On mobile everything stacks to one column and the result figure moves above the inputs so the number is always visible. The Landing page uses the same grid: hero headline flush-left across 8 columns, schematic sun-path diagram on the right, numbered three-step strip below.

Imagery style. Diagrammatic only. A schematic solar geometry diagram — sun arc, panel plane, angle arcs, cardinal directions — drawn with 2px strokes in ink and red on paper ground, labelled with Fira Sans uppercase micro-labels. A small world map with latitude bands in yellow. No photography, no illustration for its own sake, no clip art. Icons are 1.5px stroke pictograms (sun, panel, compass, cloud) in the Spiekermann pictogram tradition.

Readable text and controls. Headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit. No other element covers any part of them. Imagery and decoration may be cropped, bled off an edge, rotated, overlapped or cut as the direction asks, provided they cover no readable text or control.

7. Signature Design Concept

The instrument face.

The Landing page is composed as the face of a measuring instrument rather than a marketing page. On the warm paper ground (#F4F1EC), the headline Solar radiation, measured properly is set flush-left in Fira Sans Bold at 40px mobile / 72px desktop, spanning the left 7 columns, with a single red rule (#C8102E) beneath it. To its right, occupying 5 columns, sits the schematic sun-path diagram: a quarter-circle arc in red, the panel plane in ink, angle ticks in yellow, and micro-labels — TILT 35°, AZIMUTH 180°, LAT 48.2°N — in uppercase Fira Sans. This diagram is the only image on the page.

Below the headline runs a horizontal strip of four colour-coded data chips, reading like a transit departure board: GHI 4.82 kWh/m², DNI 3.91, DHI 0.91, TEMP 18°C. Each chip is a white panel with a 4px coloured left border, teaching the transit-line colour code — red for total, yellow for beam, grey for diffuse — in one glance.

Beneath the chips, the numbered three-step strip — 1 · LOCATION, 2 · GEOMETRY, 3 · RESULT — uses red numerals and hairline vertical dividers, echoing Spiekermann's wayfinding systems.

The composition is deliberately not centred, carries no gradient, and offers no blue button. It reads as an instrument face: a labelled, ruled, colour-coded surface that tells the user what is measured and how, before they enter a single value.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the schematic sun-path diagram — the red quarter-circle arc, the ink panel plane, and the yellow angle ticks with their uppercase micro-labels.
• Input → transformation → outcome thesis: as the user moves from reading the hero to reading the data chip strip, the component colour code established by the diagram's arc and ticks is carried into the chips' left borders, so the user arrives at the Calculator already knowing that red means total, yellow means beam and grey means diffuse. No new behavior is introduced; the transformation is purely the transfer of an already-accepted colour code from the diagram to the chips.
• Motion vocabulary: functional and short. Input focus draws a 2px red underline from left to right in 140ms. The Calculate control triggers a 180ms count-up on the result figure, with tabular numerals rolling in place. Result rows fade in staggered 40ms apart after the count settles. No bounces, no parallax, no particles.
• Composed first frame: the headline flush-left across the left 7 columns with the red rule beneath it; the sun-path diagram complete and static in the right 5 columns; the four data chips fully rendered below the headline with their coloured left borders visible. Nothing is mid-animation on first paint.
• Reduced-motion state: under prefers-reduced-motion, the count-up becomes instant and the input underlines appear without transition. The first frame is unchanged, and every figure and label is fully readable.

9. Non-Functional Requirements

NFR-1 — Numeric legibility explicit All numeric readouts use tabular figures so digits align in columns. The result figure is 56px on mobile and 96px on desktop. Rationale: the user must be able to read and defend the number at a glance.

NFR-2 — Readable text and controls at every viewport explicit Headlines, wordmarks, labels, numbers, card text and controls remain entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit. No element covers any part of them. Rationale: the instrument must be usable on the devices its audience carries.

NFR-3 — No blue or indigo explicit The palette contains no blue or indigo. Signal colours are red (#C8102E) and mustard yellow (#F2A900) only. Rationale: the direction deliberately avoids the default solar-app blue.

NFR-4 — No shadows, blur or glass explicit No drop shadows, no blur, no glassmorphism, no frosted panels. Separation is carried by 1px hairline rules and 2px section rules. Rationale: the grid is visible and proud.

NFR-5 — Reduced-motion support explicit Under prefers-reduced-motion, the result count-up becomes instant and input underlines appear without transition. Rationale: motion is functional, never decorative, and must never obstruct reading a figure.

NFR-6 — Input validation before computation required_inference The calculation does not run on an incomplete or invalid input set; the offending field is named and the previously displayed result is left intact. Rationale: a radiation figure produced from an invalid input set would be indefensible, which contradicts the product's stated purpose.

NFR-7 — No identity requirement required_inference Neither destination requires an account, sign-in, or stored profile. Rationale: no accepted journey requires durable actor-specific state, a stored history, or a commitment bound to a participant.

10. Tech Stack

• Frontend: React — a single-page web application with two routes, Landing and Calculator. [Default — not specified by user]
• Styling: CSS with the token set defined in Section 6; Fira Sans loaded as the heading and body family. [Default — not specified by user]
• Backend: Python with FastAPI, exposing the calculation endpoint that consumes the input set and returns the radiation values. [Default — not specified by user]
• Storage: none required. The accepted scope holds no durable state; the input set and result live in the Calculator page's working state for the duration of the session. [Default — not specified by user]
• Packaging: Docker with docker-compose for local development and deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required for this deployment. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• A1 — The calculation engine is owned by the application and runs server-side behind a first-party endpoint. [Default — not specified by user]
• A2 — The input set is Latitude, Longitude, Tilt, Azimuth, Date, Time and Cloud Cover, as named in the creative direction's layout specification. [Default — not specified by user]
• A3 — The result breakdown rows are Direct Normal, Diffuse Horizontal, Global Horizontal and Extraterrestrial, as named in the creative direction's layout specification. [Default — not specified by user]
• A4 — The result figure is expressed in kWh/m², consistent with the unit shown on the Landing page data chips. [Default — not specified by user]
• A5 — The Landing page's data chip values and sun-path micro-labels are illustrative instrument-face content, not live computed output. [Default — not specified by user]

Constraints

• C1 — The palette, typography, shape language, layout grid, motion tempo and imagery style in Sections 6 and 8 are binding.
• C2 — No blue or indigo appears anywhere in the product.
• C3 — Fira Sans is the primary family; Inter, Roboto, Poppins, Montserrat and other geometric sans families are excluded.
• C4 — No photographic hero imagery, no stock photos of solar panels or people in hard hats.
• C5 — No centred hero text with a subheadline and a pill button beneath it.
• C6 — No gradient blobs, glassmorphism, frosted panels or drop shadows.
• C7 — No decorative motion, particles or scroll-jacking.
• C8 — No icon-only inputs; every field is named in visible uppercase type.
• C9 — The current delivery horizon covers only computing solar radiation values from user-provided inputs and showing the result. Saved sites, comparison across locations, export, historical archives and third-party data feeds are outside the current boundary.
• C10 — No account creation, sign-in, profile or saved-project management is in scope.

12. Glossary

• Solar radiation — the energy received from the sun per unit area, expressed here in kWh/m².
• GHI (Global Horizontal Irradiance) — the total solar radiation received on a horizontal surface.
• DNI (Direct Normal Irradiance) — the solar radiation received on a surface held perpendicular to the sun's rays.
• DHI (Diffuse Horizontal Irradiance) — the solar radiation received on a horizontal surface from scattered sky light, excluding the direct beam.
• Extraterrestrial radiation — the solar radiation incident at the top of the atmosphere, before atmospheric attenuation.
• Tilt — the angle of the collector plane from horizontal.
• Azimuth — the compass direction the collector plane faces.
• Cloud cover — the fraction of the sky obscured by cloud, supplied as an input.
• Input set — the complete collection of values the user supplies for one calculation: Latitude, Longitude, Tilt, Azimuth, Date, Time and Cloud Cover.
• Result — the total radiation figure and the breakdown rows produced by a completed calculation.
• Transit-line colour code — the product's convention of marking radiation components with a 4px coloured left border: red for total, yellow for beam, grey for diffuse.
• Instrument panel — the Calculator's two-column layout: the input stack on the left, the result figure and breakdown table on the right.
• Tabular figures — a numeric font setting in which every digit occupies the same width, so figures align in columns.