Reporting uncertainty to downstream systems

"A confidence score nobody downstream reads is just a number keeping the log file warm."

A Pragmatic AI Agent

This section assumes you have a prediction with an attached uncertainty object from earlier in the chapter, and it builds on the probability and estimation vocabulary from Chapter 4. Where uncertainty feeds a recursive estimator we lean on the Kalman machinery of Chapter 9, and where it crosses a fusion boundary we anticipate Chapter 49.

What a downstream consumer actually needs

Different consumers need different shapes of uncertainty, and shipping the wrong shape is a silent bug. A recursive Bayesian filter needs a variance or covariance so it can weight your measurement against its prior; handing it a conformal prediction set is useless because the filter has no slot for a discrete set. A safety monitor needs a hard interval with a coverage guarantee so it can reason about worst case; handing it a Gaussian standard deviation forces it to assume normality your residuals may violate. A classification router needs per-class calibrated probabilities plus an abstain flag; a human dashboard needs a scalar it can threshold and a plain-language qualifier.

The practical rule: report uncertainty in the native algebra of the consumer, and report the raw sufficient statistic rather than a lossy summary whenever bandwidth allows. A predictive distribution can always be reduced to a variance or an interval downstream, but you cannot reconstruct a distribution from a single scalar. When you must compress, compress at the edge of the consumer, not at the source.

A serialization contract that survives the wire

A durable uncertainty report carries five things: the point estimate, an explicit uncertainty representation tagged by kind, the semantics of that representation (the nominal coverage or the distributional family), provenance (model version, calibration timestamp, whether adaptive conformal was active), and a validity window. The provenance fields are what let a downstream monitor in Chapter 69 later ask "was this interval produced by the recalibrated model or the stale one?" The code below defines such a contract and, critically, a converter that turns a conformal interval into the measurement-noise variance a Kalman update expects.

from dataclasses import dataclass, asdict
from enum import Enum
import json, math

class Kind(str, Enum):
    GAUSSIAN = "gaussian"          # carries mean + variance
    INTERVAL = "interval"          # carries [lo, hi] + coverage
    PREDICTION_SET = "pred_set"    # carries a set of labels + coverage

@dataclass
class UncertaintyReport:
    value: float                   # point estimate
    kind: Kind
    payload: dict                  # kind-specific fields
    coverage: float | None         # nominal guarantee, e.g. 0.9
    model_version: str
    calibrated_at: str             # ISO timestamp of last recalibration
    adaptive: bool                 # was ACI/PID active this step?

    def to_json(self) -> str:
        d = asdict(self); d["kind"] = self.kind.value
        return json.dumps(d)

def interval_to_measurement_variance(r: UncertaintyReport) -> float:
    """Feed a conformal interval into a Kalman R by matching coverage width
    to a Gaussian sigma. For 90% two-sided coverage, half-width = 1.645*sigma."""
    assert r.kind == Kind.INTERVAL and r.coverage is not None
    lo, hi = r.payload["lo"], r.payload["hi"]
    half_width = (hi - lo) / 2.0
    tail = (1.0 - r.coverage) / 2.0            # one-sided tail mass
    z = _inv_norm_cdf(1.0 - tail)              # z for that quantile
    sigma = half_width / z
    return sigma * sigma                       # variance -> Kalman R entry

def _inv_norm_cdf(p: float) -> float:          # Acklam approximation
    a=[-3.969683028665376e+01,2.209460984245205e+02,-2.759285104469687e+02,
       1.383577518672690e+02,-3.066479806614716e+01,2.506628277459239e+00]
    b=[-5.447609879822406e+01,1.615858368580409e+02,-1.556989798598866e+02,
       6.680131188771972e+01,-1.328068155288572e+01]
    c=[-7.784894002430293e-03,-3.223964580411365e-01,-2.400758277161838e+00,
       -2.549732539343734e+00,4.374664141464968e+00,2.938163982698783e+00]
    d=[7.784695709041462e-03,3.224671290700398e-01,2.445134137142996e+00,
       3.754408661907416e+00]
    pl=0.02425
    if p<pl:
        q=math.sqrt(-2*math.log(p))
        return (((((c[0]*q+c[1])*q+c[2])*q+c[3])*q+c[4])*q+c[5])/((((d[0]*q+d[1])*q+d[2])*q+d[3])*q+1)
    if p<=1-pl:
        q=p-0.5; rr=q*q
        return (((((a[0]*rr+a[1])*rr+a[2])*rr+a[3])*rr+a[4])*rr+a[5])*q/(((((b[0]*rr+b[1])*rr+b[2])*rr+b[3])*rr+b[4])*rr+1)
    q=math.sqrt(-2*math.log(1-p))
    return -(((((c[0]*q+c[1])*q+c[2])*q+c[3])*q+c[4])*q+c[5])/((((d[0]*q+d[1])*q+d[2])*q+d[3])*q+1)

rep = UncertaintyReport(
    value=21.4, kind=Kind.INTERVAL,
    payload={"lo": 19.8, "hi": 23.0}, coverage=0.90,
    model_version="tcn-v7", calibrated_at="2026-07-10T04:00:00Z", adaptive=True)
print(rep.to_json())
print("Kalman R entry:", round(interval_to_measurement_variance(rep), 4))

Propagating uncertainty through fusion and control

A report that stops at the first consumer is half wasted. In a real stack the estimate flows onward: a per-sensor variance enters a fusion node, the fused covariance enters a planner, the planner widens its safety margin. Each hop must preserve the uncertainty's meaning under the transform applied to the value. When a downstream node applies a nonlinear function \(g\) to your estimate, a first-order propagation of variance is $$\sigma_y^2 \approx \left(\frac{\partial g}{\partial x}\right)^2 \sigma_x^2,$$ which is exactly the linearization the extended Kalman filter uses and which fails when \(g\) is strongly curved near the operating point. That failure is why some pipelines forward samples or full distributions rather than a scalar variance: a sample-based representation propagates through any \(g\) by construction, at the cost of bandwidth. The choice between forwarding a variance, an interval, or a set of samples is a bandwidth-versus-fidelity decision you should make deliberately per link, and it interacts with the streaming and latency budgets of temporal models running on the edge.

Monitoring the contract in production

A shipped uncertainty contract is a promise ("90% of my intervals cover the truth") that you must audit against reality, because coverage silently decays under the distribution shift covered in Chapter 66. The observability layer should log, per report, the point estimate, the interval width, the coverage claim, and later, when ground truth or a delayed label arrives, whether the interval actually covered. A rolling empirical coverage that drifts below the nominal level is the earliest, cheapest drift alarm you own, and it is far more actionable than raw accuracy because it points directly at the uncertainty head. Log the model_version and calibrated_at fields alongside so that a coverage regression can be attributed to a specific deploy. This closes the loop with the fleet operations discipline of Chapter 69: the same telemetry that proves your calibration in the lab must keep proving it in the field.

What's Next

In Chapter 19, we leave bespoke per-task models behind and enter the pretrain-once, adapt-anywhere era of time-series foundation models. The reporting discipline you just built becomes even more load-bearing there: a zero-shot forecaster emits full predictive distributions with no clean calibration set, so the contract, the coverage audit, and the provenance fields are how you keep a general-purpose model honest on your specific sensors.