I built a light pollution map (link at the end of the article). Click anywhere, and you get a Bortle class, a sky-brightness (SQM) value, a rough count of naked-eye stars, a suggested camera exposure time, a multi-year brightness trend.

Not one of those is a measurement. They're all derived from a single satellite raster — NOAA's VIIRS night-light composite for 2024 — pushed through a chain of simplified formulas. The radiance-to-brightness step is a fitted log curve, not an atmospheric model. The Bortle class is binned from that modeled value. The star count is estimated from the Bortle class. The exposure suggestion adds a noise-budget model with an empirically calibrated constant on top.

Every one of those numbers could be wrong in a specific, predictable direction, and I know roughly which direction for each. The interesting product question isn't how to make them more accurate — the data has hard limits. It's where the caveats go.

My claim: when your output is an estimate and a real person will act on it, the explanation of how you got there is not legal boilerplate for the footer. It's a first-class feature, and it should be about as visible as the number.

Why it isn't optional

People act on the number. Somebody reads "Bortle 3, clear skies Thursday" and drives two hours at night to a spot they've never seen. If the composite is a year stale, if the pixel averaged in a gas station that opened last spring, if VIIRS undercounted the new LED floodlights because its sensor is weak in blue — that drive is the cost of my silence about the assumptions. The number implied a confidence the pipeline doesn't have.

Writing the caveats makes you honest with yourself. You cannot write "step 2 is a simplification" without finishing the sentence. Simplified how? Compared to what? Off by how much, and which way? The act of documenting forces you to actually know your own error bars instead of vaguely gesturing at them. Half the value of my methodology page is that writing it changed what I built.

It's the actual differentiator. Look at the category. A lot of tools in this space hand you a confident Bortle number and say nothing about provenance. That reads as more authoritative. It is not more accurate — it's just quieter about the same uncertainty everyone in the category is sitting on. Being the one that shows its work is a smaller market position and a more defensible one.

What "visible" looks like in practice

Concretely, on this map:

• The methodology lives on its own page, structured as three steps — satellite input, the simplified brightness model (named as simplified, with the real atmospheric model it is not), and the public-facing interpretation layer where Bortle class is derived rather than observed.
• Every estimated feature restates its own approximation where it's shown. The exposure calculator says it's a simplified estimate for reference. The clear-nights stat says it's a climate average, not a forecast for any specific night. The photo-brightness analyzer — the shakiest feature on the site — carries the bluntest disclaimer of all: that the map's own satellite-derived numbers are more reliable than what it just told you.
• The data year is on the map, not buried. "2024 annual composite" is a fact the user should have before they trust a trend line.

None of this is elaborate. It's a page and a sentence per feature. The cost is low; the thing it buys — a user who knows what they're holding — is the entire point of publishing an estimate at all.

The counterargument, and its limit

The obvious objection: most products don't do this, and users don't ask for it. A weather app doesn't make you read about numerical weather prediction. A maps app doesn't footnote its ETA model.

Fair — for outputs where the stakes of being wrong are low and self-correcting. You notice the ETA was off when you arrive; you adjust next time. But when the output is a one-shot decision input — go or don't go, this site or that one, this exposure or that one — and the user has no cheap way to check it against reality before acting, then "clean UI, no caveats" isn't minimalism. It's transferring your uncertainty onto someone who doesn't know they've received it.

The disclaimer isn't there to protect me. It's there so the number means what the user thinks it means.

Where I'd draw the line

I'm not arguing every product should be this verbose. If your model is well-calibrated, continuously validated, and the user gets fast feedback on errors, a quiet number is fine — earned, even.

The rule I'd actually defend is narrower: if the output is an estimate, and there's a human downstream who will act on it before they can verify it, then how you made that estimate is part of what you shipped. Ship it visibly, or accept that "simple" was doing some work it shouldn't have.

Light Pollution Map.