Why Uncertainty Matters
How confidently an artifact reflects the truth — at the moment you actually use it
The previous article left us with two balances. Both committed. Both Level 1 invariant aggregates. Both carrying claims of the same tier. One updated in real time, one updated nightly. On every facet named so far, identical — and yet for a decision about the current position of the account, one is trustworthy and one may be twenty-three hours wrong.
The facet that separates them is epistemic uncertainty: how confidently an artifact reflects the truth it claims to represent, at the moment of consumption. Not how strong the claim is in principle, not whether someone committed to it, not how far it sits from the atoms — but whether this instance, right now, can be acted on safely. It is the facet of fitness for use.
It has three components, and a system that wants to use an artifact responsibly must characterise all three.
Component one — temporal uncertainty
The first component is staleness: the time between when the ground truth was established and when the artifact reflects it. For the real-time balance, milliseconds. For the nightly balance, up to twenty-four hours.
What matters is not the raw delay but the delay relative to how fast the underlying truth changes. Two minutes of staleness is nothing for a patient’s recorded height and potentially catastrophic for a live market price. Temporal uncertainty is best understood as a distribution over the question how much could have changed since this was computed? — and that distribution depends entirely on the phenomenon.
The decisive property: temporal uncertainty must be characterised and published by the producer. A consumer who does not know the staleness profile of what they are using cannot make a calibrated decision about it. The nightly balance is not dangerous because it is nightly; it is dangerous when it is nightly and the consumer does not know that.
Component two — probabilistic computation loss
The second component is information lost in the computation that produced the artifact, even with perfect inputs.
A deterministic transformation — a sum, a sort, a join, a deterministic derivation — introduces no stochastic loss: the same inputs always produce the same output (η = 1 for the probabilistic component). That is not the same as preserving full detail about concrete atomic committed ground truth — generalization forgets which atoms supported the conclusion, and the step sits at a higher aggregate level, not at the irreducible substrate. A probabilistic computation — a trained model, a human judgment, a forecast — adds genuine stochastic loss on top: the same inputs on a different occasion might produce a different output. That loss is captured by η running from 1 down toward 0.
Two things make this component sharp. First, it compounds. A chain of three probabilistic steps at η = 0.9 each preserves only about 0.73 of the original information — before any staleness is counted. Long pipelines of model-on-model inference bleed information at every stage. Second, some of the loss is not random noise that averages out but systematic, directional bias — human judgments from a training corpus compressed into model weights and applied as if objective. This is the deep reason a fluent model output can be confidently, repeatably wrong in the same direction: it is not noisy, it is biased, and bias does not wash out with more samples. The Confident Deck, generated at machine scale, is high probabilistic-computation loss wearing the costume of a clean result (LLMs at the Commitment Boundary names this frozen collective subjectivity).
Component three — cross-stream consistency
The third component — cross-stream consistency — is subtler and routinely missed. A view that combines several streams can be fresh and accurate within each stream and still show a state that never simultaneously existed.
The balance stream is current as of 14:32:07. Inventory as of 14:32:04. Pricing as of 14:31:58. Each figure may be correct on its own; the combined dashboard presents three different instants as one — a snapshot of a moment that never happened. That gap is often processing lag (independent refresh cadences), not clock failure. Clocks can also skew between hosts, but inside a single well-run system skew is usually small relative to business phenomena — and timestamps still give a pragmatic synchronisation point: an as-of instant, a materialised snapshot, or a query cut-off at T can align streams with high probability that the values belonged to the same wall-time neighbourhood.
That alignment is policy, not magic. Residual cross-stream uncertainty remains — bounded skew, races between write and read, causal order not yet visible across writers. Characterise it; do not assume it away. In many enterprise uses the residual is U-low and irrelevant to the decision. In others it is not: automated rules that treat unrelated refresh times as simultaneous, federated systems without a shared clock domain, or closed-loop physical control — robotics, motion, safety interlocks — where sub-millisecond mismatch can be catastrophic. The facet is the same; stakes and domain set the threshold.
Three hazards are worth separating:
This is distinct from staleness (within one stream) and from computation loss (within one step). Distributed systems theory names two guarantees that sharpen the question:
Serializability. The combined outcome could have been produced by some serial execution of the underlying updates — no impossible interleaving of reads and writes. A snapshot query or repeatable-read transaction at a cut-off time is often serializable: the database presents a state that existed at some point in a valid history, even if individual streams were read at slightly different internal phases.
Linearizability (Herlihy & Wing). Stronger: each operation appears to take effect atomically at a single instant between its invocation and response, and real-time order is preserved — if operation A completes before B begins, A’s effect is visible before B’s. A multi-stream view that is linearizable at wall time T is one a closed-loop controller or invariant enforcer may treat as a true simultaneous cut. Per-stream “current” values with no shared cut may fail even serializability.
The causal consistency criterion from above still applies across writers: for any two events where one caused the other, a consistent view contains both or neither. Serializability and linearizability are the engineering names for when that criterion is enforced by infrastructure rather than hoped for at read time. Timestamps plus bounded skew approximate a cut for many enterprise reads; they are not a substitute for declaring — in the contract — whether the artifact is a serializable snapshot, a linearizable register read, or best-effort stitching.
Impossible simultaneity is the read-path failure when this component is high and undisclosed — a polished combined view treated as linearizable or serializable when it is neither.
The three components at a glance
Epistemic uncertainty is composite: each component asks a different question, fails in different ways, and must be disclosed separately. U-low, U-med, and U-high summarise the combined judgment for a use case — domain and stakes set the thresholds; the components explain why.
Temporal uncertainty is about time since capture. Probabilistic loss is about information destroyed in processing. Cross-stream consistency is about alignment across sources. An artifact can be low on one and high on another — fresh, biased, and stitched from incompatible instants at once.
Uncertainty is a contract property
Notice what all three components have in common: they are properties the producer knows and the consumer needs, and they are useless unless they are published.
This makes uncertainty, like atomicity, a contract property. When a team publishes an artifact, characterising its uncertainty is part of the contract, alongside the schema:
- update frequency and worst-case staleness (temporal),
- information efficiency per processing step (probabilistic loss),
- which streams are combined, the as-of instant or alignment method, assumed clock domain / max skew, and consistency guarantee where known — serializable snapshot, linearizable read, or best-effort (cross-stream).
A consumer who cannot answer these questions about what they depend on is operating under unknown uncertainty — which is strictly worse than known, bounded, characterised uncertainty. The thresholds that separate low, medium, and high are not universal; acceptable staleness for a revenue dashboard is not acceptable staleness for fraud detection, and a nine-second spread across streams may be negligible for one decision and fatal for another. The facet provides the structure; the domain provides the thresholds. Either way, the obligation is the same: say how confident your artifact deserves to be treated as, or it cannot be used responsibly at all.
Independent of everything else
Uncertainty is, once again, orthogonal to the other facets — and the orthogonality is what makes it worth naming separately.
A tier-3 empirical claim can be served stale and inconsistent, and so be unsafe to act on this instant despite its strength. A committed, atomic, real-time observation from a badly calibrated sensor is low-staleness and high computation-loss at the same time — fresh and wrong. A high-weight authority’s committed judgment can be perfectly current or hopelessly out of date. Freshness is not strength, is not commitment, is not standing, is not depth. It is its own question: can I rely on this, now?
Five artifact facets — and a sixth on the processor
To know how much to trust an artifact on its own merits, we ask:
- Tier — how strongly is the underlying claim supported?
- Commitment status — has a named authority committed to it as accountable fact?
- Authority weight — how much does that committer’s standing count here?
- Atomicity — how far is it from the irreducible substrate?
- Uncertainty — how confidently does it reflect the truth right now?
These five are genuinely independent on the artifact side; none reduces to another. They are not yet the whole answer — because real commits are made by processors (people, panels, certified workflows) who may distort tier, ignore uncertainty, or rubber-stamp. The sixth facet, processor fidelity (disposition), is developed in Disposition and Processor Fidelity immediately before composition in The Facets Composed.
Together, six inputs resolve into one question every consumer and every decision asks: how much may I trust this, for what I am about to do with it? The Facets Composed is the synthesis — how the facets compose, how they constrain what may depend on what, and how they resolve into a single judgment of trust and risk.