The closure principle in cloud infrastructure
Here is the objection at full strength. Closure is not settled doctrine in epistemology, and importing it wholesale into systems design borrows a shakier foundation than the pitch admits. Fred Dretske's zebra: you can know the animal in the enclosure is a zebra without knowing it is not a cleverly disguised mule, because your evidence was never sensitive to that alternative in the first place. Robert Nozick built a whole tracking theory on the same denial. If knowledge does not close under every entailment you happen to draw, then the entire argument that a stale premise poisons its deductive cone loses its engine. Warrant does not have to flow downhill just because a valid inference was drawn. Apply that to an incident review: an on-call engineer who correctly diagnosed a timeout as a downstream latency issue does not thereby need to have known, at diagnosis time, every service that transitively depends on the latent component. Demanding that is demanding omniscience dressed up as rigour.
That is a real objection, not a straw one, and it deserves to be taken at its word before it is narrowed.
What the sceptic's case actually targets
Dretske and Nozick were fighting scepticism, not observability. The zebra case works because the entailed proposition — not a painted mule — is precisely the proposition your evidence was structurally incapable of ruling out. No amount of looking at stripes helps. That is a special kind of entailment: one across an alternative your sensing apparatus cannot discriminate.
Service reliability engineering runs almost entirely on the other kind. When a Site Reliability Engineer marks a downstream queue as "durable" because its underlying storage backend has historically offered 99.999% durability, and later builds a retry policy, a data-loss tolerance budget, and a customer SLA on top of that premise, the entailment from "backend is durable" to "retry-then-drop is safe" is not a sceptical alternative. It is a mundane, tracked, engineering inference. If the storage backend's durability profile changes — a new erasure-coding scheme, a quietly demoted replication factor, a region migrated onto cheaper media — the SRE's evidence was never insensitive to that fact by nature. It was insensitive because nobody wired up a channel to report the change. That is the failure this page is about, and it is not touched by the zebra case. Deny closure across every entailment and you also lose the ability to say a corrected premise obliges a corrected conclusion about anything, which is not a position any incident review would accept from an engineer.
The dependency graph as deductive cone
Cloud systems already have a name for the deductive cone: the dependency graph. A service's SLA is not a fact about that service. It is a conclusion inferred from the SLAs, latency profiles and failure modes of everything it calls, cached from everything those services call, recursively. Terraform state, service meshes and dependency-tracking tools like sends-to graphs in observability platforms exist precisely because nobody can hold the whole cone in their head.
The characteristic failure of this domain is exactly the closure failure the principle predicts: a dependency is trusted long after its reliability profile changed. A managed database that shipped with single-AZ durability gets migrated by its vendor to multi-AZ, and every downstream retry budget calculated against the old failure rate is now conservative rather than wrong — no incident there. Run the change the other direction and the story is worse. A message broker that used to guarantee at-least-once delivery gets reconfigured, under cost pressure, to a lower durability tier, and nobody tells the seventeen services whose idempotency keys and reconciliation jobs were designed around the old guarantee. The change is a single line in a config diff. The cone it invalidates is every service that inferred correctness from that broker's old contract, and none of them re-derive their assumptions on every deploy. They inherit them, the way a flight crew inherits a route from a navigation database rather than re-deriving it from raw coordinates.
Decay is not enough
The next objection concedes more ground and is harder to dismiss. Most reliability engineering is already probabilistic, not deductive. Error budgets, SLO burn-rate alerts, exponentially weighted moving averages on latency — these are Bayesian instruments. They down-weight ageing telemetry automatically and reconverge as fresh data arrive. Nobody needs a channel for defeaters if every belief already carries a half-life.
Decay handles the case where staleness is continuous and its rate is known in advance: a metric that drifts, a load pattern that shifts gradually with the season. It fails at exactly the case that produces the worst incidents — a discontinuous change to a dependency's contract, not its performance. A cloud provider deprecating an API version, a certificate authority revoking a root, a third-party CDN silently changing its cache-invalidation semantics: none of these announce themselves as a gradual drift a decay function can track. They are step changes, and no prior over elapsed time gets you there. Only an event does — a deprecation notice, a changelog entry, a deploy event correctly parsed and linked to what depends on the changed component. The 2021 pattern of certificate-related outages that took down otherwise-unrelated services when a root CA expired is the domain's version of the LIBOR cessation: one artefact, invisible until it wasn't, underneath more inferred conclusions than anyone had enumerated.
The tractability half of the objection is fair and should be conceded outright. Full truth maintenance across a service graph with tens of thousands of nodes is not a plausible undertaking; recomputing every downstream SLA on every dependency change would drown the platform in its own bookkeeping. But the remedy this argument needs is scoped, not total: record which upstream facts a given SLA, retry policy or capacity plan actually used, and propagate invalidation along that recorded edge when the fact changes. That is bounded work — proportional to the recorded dependency, not to the whole graph — and it is precisely what a deploy-event feed linked to a dependency graph is for, when it is built to be queried backwards from a change rather than only forwards from a deploy.
Provenance does the work, but only if intake stays open
The sharpest version of the third objection says the real engineering value is in the dependency graph and the incident feed, not in some abstract commitment to "open intake." A platform with a small number of well-instrumented signals and rigorous lineage tracking will outperform one that ingests every telemetry stream, dependency graph and deploy log indiscriminately and drowns in cardinality. Calling this an intake problem, rather than a provenance-and-tooling problem, misdescribes where the value sits.
This is the strongest form of the objection and half of it should simply be granted. Provenance is what turns an arriving signal into a retracted conclusion. Telemetry without lineage is noise with a timestamp; nobody disputes that. But provenance can only revise beliefs against defeaters that arrive. A well-chosen, narrow set of signals is chosen against some model of which premises are likely to change — and that model of what to watch is itself a premise, one that can go stale exactly like the durability guarantee above. The team that decided three years ago which five services were "critical path" and instrumented only those has built a closure failure into its own monitoring strategy the moment a sixth service quietly became load-bearing. The claim this page is defending is narrower than "watch everything": it is that the channel for defeaters must not be closed in advance, at the level of policy. Which streams get weighted heavily, sampled finely, or escalated fast is exactly the downstream work of scale, trust and cost that follows once the channel itself stays open — a genuinely difficult, ongoing engineering problem, but a different one from whether the channel exists at all.
What survives
The narrow claim holds even after both concessions. Cloud infrastructure runs on inference chains — SLAs, retry policies, capacity plans — built from premises about dependency behaviour. When one of those premises changes, the cost is not the size of the change, a single config line or a deprecation notice; it is the size of everything correctly, validly inferred from it before the change was noticed. Continuous telemetry, dependency graphs and deploy feeds are not decoration on top of good operational practice. They are the minimum structure by which a discontinuous change to a dependency's contract can be traced to the SLAs, budgets and runbooks derived from it, and those derivations withdrawn before an SRE inherits a guarantee that no longer exists.