Semantic satiation and drift of meaning in cloud infrastructure

The word that kept its spelling

An SRE at 3 a.m. reads a dashboard that says the payments dependency is "healthy" and moves on. The word has not changed. The dependency has. Six weeks earlier, the team behind that service migrated its retry logic, doubled its p99 latency budget, and quietly reclassified itself from a synchronous critical path to a best-effort async one. Nobody renamed it. It is still called `payments-core` in the dependency graph, still tagged `tier-1`, still green on the status page. The token survived; the referent moved underneath it. This is semantic drift, and cloud infrastructure runs on exactly the kind of long-lived, rarely-renamed vocabulary where drift does its quietest damage.

Psychologists who study semantic satiation found something adjacent at a much shorter timescale: say a word thirty times and it goes briefly dead, sound detached from sense. Linguists who study semantic change found the long version: a word's referent migrates while its spelling stays put, and nothing in the surface warns you. Infrastructure has its own dialect of this. "Trusted dependency," "critical path," "tier-1 service" — these are labels applied once, at onboarding, and then trusted for years because relabelling is expensive and nobody owns the job of re-checking an assumption that was correct when it was made.

Two positions, both defensible

Set them against each other honestly.

Position A: freshness is a data problem, not an architecture problem. Telemetry pipelines already stream metrics at sub-second resolution. Dependency graphs are rebuilt on every deploy. Incident feeds are timestamped to the millisecond. An SRE platform that re-ingests configuration and health signals every few minutes is, by any reasonable measure, already doing continuous intake. If a dependency's reliability profile changed, the metrics reflect it within the next scrape interval. The claim that infrastructure tooling suffers from a "frozen corpus" problem misunderstands the domain: nothing here is frozen. The failure mode described — a stale trust label — is an alerting gap, fixable by tightening the SLO monitors that should have flagged the latency regression, not evidence of some deeper limit on what a system is permitted to observe.

Position B: continuous metrics are not the same as continuous meaning. The telemetry stream can update the number — p99 latency, error rate, retry count — every second, and still leave the interpretation of that number frozen at onboarding time. "Tier-1" is not a metric. It is a claim someone made about what a metric implies, attached once, rarely revisited, and carried forward by every downstream system that reads the tag rather than the history behind it. The dashboard streams data; the label streams nothing. This is precisely the asymmetry that matters: high-frequency intake of raw signal coexists with zero intake of the definitions that give the signal meaning.

Both of these are correct, which is the point. The domain genuinely does stream telemetry continuously — that concession is real and should not be minimised. What it does not stream, in most shops, is the provenance of the judgements layered on top of that telemetry: who decided this was tier-1, under what load profile, on what date, and whether that decision was ever revisited when the load profile changed.

Where the label outlives the fact

The characteristic failure names itself: a dependency is trusted long after its reliability profile changed. Unpack the mechanism. A service's SLA, its blast radius, its failure mode — these are established once, usually during an incident postmortem or an initial integration review, and encoded as a static attribute: a tag, a priority field, an entry in a service catalogue. The underlying reality keeps moving. Ownership transfers between teams. The service gets rearchitected from a monolith call to a queue-based one, changing its failure semantics from synchronous blocking to eventual consistency. A dependency that used to fail loudly and immediately now fails silently and late. None of this triggers a re-labelling event, because the label was never wired to the thing that changed. It was wired to a decision made on a specific date, and that date is nowhere recorded.

This is structurally identical to the sepsis redefinition or the IAU's reclassification of Pluto: the token is durable, the definition underneath it is not, and text — or in this case, configuration — written either side of the redefinition uses one word for two different referents. A dependency graph assembled in January and one assembled in September may both say "hard dependency, tier-1, 99.99% SLA" for the same node while meaning structurally different things by it, because the service's actual behaviour under load has diverged from the assumptions the label encodes.

The two objections worth taking seriously

"Observability tooling already streams everything; this is an alerting configuration problem, not an architectural limit." Concede the premise and hold the conclusion at arm's length. Metrics pipelines stream continuously — that is real, and no argument here should pretend otherwise. But alerting fires on thresholds defined against the old model of the dependency. If nobody updates the SLO because nobody knew the dependency's failure semantics had changed, the alert rule itself is stale, and a stale alert rule does not know it is stale. Streaming the number faster does not repair a threshold set against an assumption that expired. The gap is not in ingestion rate; it is in the absence of a dated claim — "this dependency was synchronous and blocking as of March; as of September it is queued and eventually consistent, source: architecture review, ticket #4471" — that could be checked against current metadata and flagged as superseded. Retrieval-style fixes (querying the latest deploy event when an alert fires) help only if someone thinks to query. Silent drift, by definition, gives no cue to query.

"Reliability profiles for core infrastructure change slowly; quarterly service reviews outrun the phenomenon." This is true on average and misleading at the tail. Most dependencies are stable for long stretches. But the ones that matter operationally are exactly the ones that change discontinuously: a migration cutover, a vendor's regional outage pattern shifting after their own infrastructure change, a database moving from synchronous replication to a new consensus protocol overnight. These are step functions, not drifts — closer to Basel III redefining Tier 1 capital by fiat than to a word's meaning eroding over decades. Quarterly review cadence is a defence against slow decay and no defence at all against a cutover that happens on a Tuesday. The distribution of risk in a dependency graph is heavy-tailed, concentrated in the services that changed suddenly and were never re-tagged, and average slowness elsewhere does not cover that tail.

What actually resolves this

Not full vindication of continuous intake as some general solvent, and not surrender to "better alerting" as sufficient. The narrower claim: telemetry volume and semantic currency are different axes, and cloud infrastructure has solved the first without solving the second. A Large Language Model analogy is instructive here for what it rules out, not what it recommends — a system trained on a corpus fixed at a cutoff would encode "tier-1 dependency" as whatever the term meant across its training window, with no mechanism to notice a redefinition after the fact. A Large World Model, grounded in a present scene, could inspect the service's current call graph directly and see the queue where the synchronous call used to be — real repair, but only for the subset of judgements you can re-derive by looking, and reliability classification is partly a policy decision, not purely observable geometry. The remainder — who decided this was tier-1, when, and under what assumptions, and whether those assumptions still hold — is provenance, and provenance is exactly what a service catalogue tag does not carry.

The resolution narrows rather than settles: continuous telemetry is necessary and cloud infrastructure mostly has it; continuous reassessment of labels against dated provenance is a separate requirement that almost nobody has, and it is the one whose absence produces the specific failure named at the top. An SRE does not need faster metrics at 3 a.m. They need the tag to carry a date and a reason, so that "trusted" comes with an expiry condition rather than a permanent, unexamined green light.