Losses in the Chain: six mechanisms by which a component's accuracy fails to reach the output

An accuracy budget describes a component. It says nothing about whether the component's number reaches anyone. Between a solar position algorithm and the figure a user reads there is a chain: an input the wrapper supplies, a threshold applied downstream, a sampling interval, the instant at which an hour-averaged input is evaluated, an input left at its default, a constant pinned at some earlier date. Each link can lose more accuracy than the choice of algorithm gains, and the chain is almost never measured. This paper reports six such losses, found in two products written by different people for different purposes. In one product, a derived input contributed three to four orders of magnitude more angular error than the algorithm it wrapped, on the paths where that input was derived rather than read. In the other, two hundredths of a degree of input moved the mean radiant temperature by 6.63 °C under a default-turbidity clear sky at one solar altitude, and by no more than 0.07 °C anywhere else between 0 and 90 degrees. In the same product, the instant at which the hourly weather data was evaluated sat at the start of the interval that data describes, half an hour from its representative middle -- a mean error of 4.15 degrees of solar altitude, present on every hour of every run. Each loss is reported with the paths it reaches, because a wrapper term that is large on a preview path and absent from the analysis path is two different findings, and collapsing them overstates the first and hides the second. Neither occurrence was found by looking for it. Both surfaced while chasing something else, and that is the paper's central claim: this class of defect is invisible to the way the field currently checks its work, because a component's accuracy is where everyone looks first.