New: description of what this project is and why it exists for a broader audience

Author: heptaflar

ABOUT.md

@@ -0,0 +1,99 @@
+# Executive Summary
+
+Modern satellite and climate data products are generated by large,
+evolving software systems. These systems effectively act as the
+“measurement instruments” in today’s workflows, and their outputs are
+used in high‑stakes decisions about climate trends, sensor performance, 
+and long‑term reprocessing. For this reason, decision‑makers increasingly 
+need uncertainty information that is not only scientifically sound, but 
+also remains in step with the software as it changes.
+
+Traditional approaches to uncertainty assume a fixed mathematical model 
+that experts can write down and analyse by hand. In practice, however, 
+the real behaviour of an operational processing chain is defined by the 
+implementation itself: many modules, multiple dependencies, and regular 
+updates. Keeping hand‑crafted formulas aligned with such a codebase is 
+difficult and expensive, and tends to break down exactly in the large‑scale,
+long‑lived projects where robust uncertainty information is most important.
+
+The approach adopted here treats the software implementation as the primary
+object and derives uncertainty information directly from it. Instead of 
+manually deriving sensitivities, we rely on capabilities that are already 
+built into modern machine‑learning libraries: they can automatically assess
+how small changes in the inputs affect the outputs, even for complex models
+and large data volumes. These capabilities are mature, openly available, 
+and widely used in industry and research, which reduces technical risk and 
+avoids locking the project into niche or proprietary tooling.
+
+At the same time, the method works with data in the way it actually appears
+in remote sensing and climate science: as images, spectra, and spatiotemporal
+fields, not just as flat tables. This allows uncertainty information to 
+reflect spatial and temporal patterns and correlations, rather than 
+collapsing everything into a single number per pixel or per product. The 
+result is an uncertainty description that is richer, more realistic, and 
+better aligned with how the data are used.
+
+> [!NOTE]
+> For management, the key benefits are: traceable and up‑to‑date uncertainty 
+> estimates that follow the evolution of the software; reuse of robust 
+> open‑source technology with a large user base; and an uncertainty framework
+> that scales to future data volumes and product complexity without requiring
+> continual manual rework of analytical models.
+
+# Technical Summary
+
+GUM, the Guide to the Expression of Uncertainty in Measurement, assumes 
+that measurement procedures can be described by relatively simple, fixed
+analytical models. A measurand is expressed as a function of a small set
+of input quantities, this function is written down explicitly, and local
+linearisation around a working point yields partial derivatives that are
+then used in the law of propagation of uncertainty. In this setting,
+Jacobians are available in closed form, and uncertainty propagation
+reduces to comparatively low‑dimensional matrix operations.
+
+This picture becomes strained once measurement procedures are implemented
+as large, evolving software systems. In many modern applications—remote
+sensing retrieval chains, satellite calibration pipelines, high‑resolution
+climate data processing—the “measurement device” is not a static laboratory
+instrument with a simple response model, but a complex codebase that changes
+as algorithms, parameterisations, and dependencies are updated. The genuine
+forward map from inputs to outputs is whatever the current version of the
+code computes. Maintaining an analytical model and its hand‑derived Jacobians
+in sync with such a code is labour‑intensive and error‑prone, and often not
+feasible at all.
+
+Algorithmic differentiation (AD) offers a way to recover the GUM 
+idea—propagation via sensitivities—without requiring a separate analytical 
+model. Instead of differentiating formulas, AD differentiates the program 
+itself. Given an implementation that computes outputs from inputs, AD 
+systematically applies the chain rule across all elementary operations 
+to obtain exact derivatives up to machine precision. This makes it possible
+to extract Jacobians and higher‑order derivatives from complex, nonlinear 
+algorithms, and to keep sensitivity information automatically aligned with 
+the current state of the code as it evolves.
+
+At the same time, the data structures involved in these applications are 
+no longer simple vectors and matrices. Remote sensing images are naturally 
+two‑dimensional, spectral imagers add a third dimension, and long‑term 
+Earth system records add time and possibly additional geophysical 
+dimensions. Treating such fields as flattened vectors discards the explicit
+spatial and temporal structure of both the data and their uncertainties. 
+A more faithful approach is to treat all quantities—inputs, parameters, 
+outputs, sensitivities, and covariance descriptions—as tensors, and to 
+formulate the law of propagation of uncertainty directly in tensor form. 
+In that formulation, propagated uncertainties arise from contractions of 
+Jacobian tensors with input uncertainty tensors over appropriate index sets,
+preserving the inherent multidimensional relationships.
+
+Together, these ideas point to a conceptual need: a framework that
+(i) regards the executable code as the measurement model,
+(ii) obtains sensitivities via algorithmic differentiation rather than
+manual calculus, and
+(iii) works natively with tensor‑valued data and uncertainty descriptions
+instead of forcing everything into vector–matrix form. 
+
+> [!NOTE]
+> After reading this, a technically inclined reader is naturally led to
+> ask: how can one implement such a tensor‑aware, AD‑based uncertainty
+> propagation framework for real‑world measurement and calibration 
+> workflows?