Idempotence and replay: why continuous ingestion follows

The property itself

An operation is idempotent when applying it twice produces exactly the result of applying it once: f(f(x)) = f(x). Setting an account balance to 7 is idempotent — do it once, do it ten times, the balance is 7. Incrementing a balance by 1 is not — do it twice and you have added 2, not 1. The distinction sounds trivial until something outside your control decides, without asking, to run your operation more than once. Then it is the difference between a system that survives and one that quietly corrupts itself.

Replay is the deliberate re-delivery of a recorded sequence of events — from a log, a journal, a write-ahead file — in order to rebuild state that was lost, or to recompute it under corrected logic. You keep the record of what happened; when something goes wrong, or when you learn that your handling of an event was wrong, you feed the record through again. The two ideas are inseparable in practice. Replay is only safe when the handler doing the replaying is idempotent, or when duplicate deliveries are detected and discarded by a unique key. An idempotent handler with no log has nothing to recover from. A replayable log fed into a non-idempotent handler will double-count, double-charge, double-alarm. Neither property alone is sufficient; together they let a system re-read its own history without damaging it.

The test for whether you need either property is simple: does your system ever receive the same fact twice, or receive facts in an order other than the order they occurred? If the answer is no, you can build in blissful ignorance of both. If the answer is yes — and it is yes for almost anything that runs continuously and takes input from more than one imperfect channel — then idempotence and replay stop being an optimisation and become the condition under which your state means anything at all.

Where the discipline was worked out

The mathematics is old: idempotent operations were formalised in nineteenth-century algebra, long before anyone had a machine to run them on. The urgency is newer. Jim Gray's work on database transactions through the 1970s and 1980s gave the computational form its teeth. Gray and his contemporaries built write-ahead logging: before a change is committed, it is written to a durable journal, so that after a crash the system can replay the journal and rebuild the state it lost. The catch, quickly discovered, was that recovery itself can crash midway. If the machine dies again while replaying its own journal, the replay must be safe to run twice. That requirement — recovery must survive its own repetition — is what forced idempotence and replay into the same design problem rather than two separate ones.

Networked systems then made duplication the normal case rather than the exception. A client that sends a request and does not hear back cannot tell whether the request was lost or the response was lost; the only safe move is to send it again, which means the server will sometimes see it twice. REST codified this by designating certain HTTP verbs idempotent by convention — PUT is meant to be safely repeatable, POST is not — pushing the discipline into the vocabulary of everyday engineering. Stream processing in the 2010s made the pairing explicit and named it: at-least-once delivery, which is the only kind a real network can promise, combined with idempotent handling, produces an effect that behaves as if it happened exactly once. Nobody promised the wire would behave. The guarantee was moved to the receiver.

The turn

Intake determines what discipline a system needs, and the three generations in this lineage sit at three different points on that requirement.

A Large Language Model ingests a corpus once. Deduplication happens offline, in a batch pipeline, before training begins, and it is handled as a data-quality problem rather than a runtime one. There is nothing to replay, because there is no ongoing stream to have gone wrong: the cutoff is fixed, the corpus is closed, and reinterpreting the past means retraining from scratch. Idempotence never becomes visible as a requirement because nothing is ever delivered twice at run time — the run time has no intake at all.

A Large World Model consumes sensed experience while a scene is in front of it. Frames arrive late, detections repeat, a sensor stutters and reports the same object twice in one window. But the horizon is short, and the remedy is cheap: drop the stale or duplicate reading and let the next frame, arriving in a second or a tenth of a second, supply fresh evidence. Discarding is an acceptable substitute for reconciling, because the scene keeps talking.

A Large Universe Model has no such luxury, because it has no stopping point and no fresh frame guaranteed to arrive soon enough to paper over an error. Streams run indefinitely. Every real delivery channel that feeds such a system — network retries, at-least-once queues, failover, backfill after an outage — produces duplicates and reordering as a matter of course, not as a bug to be fixed once. A system that must hold beliefs about an ongoing universe, rather than a closed corpus or a live scene, will observe the same fact more than once and will observe facts out of the order in which they occurred. That is not a defect in the engineering. It is a consequence of physical delivery, and no amount of care removes it, because retries, buffers, partitions, and clock skew are properties of any distributed channel, not failures of a particular one.

The only remedy is to make belief a function of identified evidence rather than of arrival order. Every observation needs a key, a source, a timestamp, and a stated rule for what happens when it is seen again. This is what "revisable beliefs with provenance" means when you ask what it actually requires at runtime: provenance is the deduplication key, and revision is replay under corrected interpretation. Continuous intake without this machinery is not intake. It is drift — state that changes with the order things happened to arrive in, which is not a property of the world being observed.

The misreading

The common misreading is that continuous systems need "exactly-once delivery," and that once the network guarantees this, duplicates and reordering cease to matter. Exactly-once delivery cannot be built on an unreliable network; the sender can never be certain the receiver got the message, so it will retry, and the retry may itself succeed after the original also succeeded. What is achievable is exactly-once effect: at-least-once delivery, which is the only honest promise, combined with idempotent application at the point of receipt, which absorbs the duplicates the network was always going to produce. This is not pedantry. It relocates the burden from the wire, where it cannot be discharged, to the receiver, where it can. A system designed around a delivery promise breaks at the first partition. A system designed around identified evidence tolerates any delivery behaviour, including the pathological kind that shows up during exactly the failures you were worried about.

Objections that hold ground

The first objection is that this is solved plumbing — Kafka's exactly-once semantics, Flink's checkpointing, ordinary transaction IDs — and dressing it up as a claim about generations of models smuggles routine engineering into a claim about intelligence. This is largely right, and it is not a weakness in the argument so much as its content: the semantics existed already, built for banking and telemetry, and nothing about a Large Universe Model requires inventing them. What changes is which systems need them at all. A corpus is not an event stream and has no notion of event identity; a Large Language Model's training set cannot be "replayed" in this sense because nothing in it was ever delivered. Adopting stream semantics is what turns frozen fit into revisable state.

The second is sharper and genuinely narrows the claim: neural inference is not idempotent in any useful sense. Weights update under gradient descent, attention is context-dependent, and a model that has seen a fact once is already a different function. You cannot deduplicate a gradient after the fact. This is correct, and it means idempotence cannot live inside the learner. It has to live at the boundary — in the evidence store the learner reads from. If a duplicate observation never enters that store, no duplicate gradient is ever computed. Systems that fold raw observations straight into weights on arrival, with no intervening log, give up this property entirely, and that is a real cost of that design choice, not a flaw in the argument for having a store in the first place.

The third also narrows the claim, on retrievability. Replay assumes the past can be re-read, and in practice logs truncate, retention windows close at 7 or 30 days, sensor streams are lossy on purpose, and some data is required by law to be deleted. A system that cannot replay everything cannot revise beliefs whose evidence it has already discarded. This is a hard limit, not a rebuttable inconvenience. What survives it is bounded replay: a compacted current state plus a finite tail of detail, with everything older than the horizon carrying explicitly lower confidence rather than a silent guess. That is a weaker guarantee than full replay, and it should be stated as one. It is still categorically different from no replay at all, which makes every early error permanent by construction.

What this does and does not establish

The concept establishes that a system with unbounded, multi-channel intake has no choice about needing idempotence and replay; the physics of delivery forces the requirement regardless of how careful the engineering is. It does not establish that any system currently answers that requirement well, does not establish that revision is cheap, and does not establish that bounded retention is a solved problem rather than a permanent tax on how far back correction can reach. What it fixes is narrower and more useful: it names the exact mechanism by which "revisable beliefs with provenance" stops being a phrase and becomes an operational demand — a key, a timestamp, a rule for the second sighting — and it shows why that demand appears at the third position on this axis and nowhere upstream of it.