The Proof Behind the Slogan

Sat, 22 Aug 2026 00:00:00 GMT

In August 2026, DeepSeek released an agent harness under the MIT licence with four words on the front of it: Everything is a Plugin. Behind those four words sits a preprint called A Programming Paradigm for Spatiotemporal Composability.

I’ve written separately about how that release made me feel. This is the other half — what is actually being claimed, for anyone who saw the slogan and, like me, assumed they’d seen the work.

They’re very different documents. The slogan describes something software has been doing since the 1990s. The paper claims something quite a lot smaller, and I think more interesting.

The part that isn’t new

A plugin is a piece you can add to a program without opening up the middle of it. Your browser’s ad blocker is one. So is a lens on a camera body. This is not a new idea and nobody involved pretends it is — the paper’s own framing is that dynamic composition is everywhere in modern software and that its formal foundations are what remain underdeveloped.

So the contribution isn’t the pattern. It’s the part underneath the pattern that nobody had written down carefully.

Two problems that sound like one

Anything built out of removable parts has two hard problems. They get talked about as one problem, and they aren’t.

The first is about time. A piece gets removed. What happens to everything it did while it was there? It registered handlers, opened connections, set values, subscribed to things. In nearly every system ever built, cleaning that up is the plugin author’s responsibility — a rental agreement, leave it as you found it. Most authors mostly do. The failures are quiet and cumulative, which is why long-running programs mysteriously sag over an afternoon.

The second is about space. Piece A needs piece B. But B might not exist yet, or might disappear halfway through, or might be swapped for a different B while A is mid-sentence. Most systems wire their dependencies together once, at startup, and after that the wiring is a fact. Change the world underneath it and you get a crash or, worse, something stale that keeps working incorrectly.

“Spatiotemporal” is not a flourish. It’s those two, and the claim that they hold together.

The time half: changes that carry their own undo

The mechanism is bookkeeping rather than magic, and that’s a compliment.

Every change a piece makes goes through the framework’s own hands, and each one is recorded along with its inverse — the paper’s phrasing is that every transformation carries an inverse the runtime tracks. Removing the piece means replaying the record backwards.

It’s double-entry accounting applied to side effects. In double-entry, you don’t clean up the books at the end of the year by remembering what you did; every entry was written with its counter-entry at the moment it happened, so the balancing isn’t a task anyone can forget to perform. Same shape here. Cleanup stops being a thing developers do well or badly and becomes a property of how change is recorded at all.

The space half: dependencies that stay awake

The other half is that a piece declares what it needs, and the framework watches. Dependency appears, the piece starts. Dependency vanishes, the piece stops. Dependency is replaced, the piece adjusts. Nobody polls, nobody crashes, nobody keeps operating on something that left the building.

The paper’s own foil here is a familiar one to web developers: React’s useEffect, where you can express “do this, and here’s how to clean it up” — but writing the cleanup correctly remains your job, and forgetting is easy and common. The claim is that in their model, complete recovery is a property of the system rather than an obligation on the developer.

What it does not promise

This is where I’d want the marketing to be more careful than it is.

The guarantee covers what goes through the framework. A plugin can still write a file, mutate a global the runtime never sees, or spawn a process — and none of that appears in the ledger, so none of it comes back on removal. Nothing here makes arbitrary side effects reversible. It makes recorded side effects reversible, and then argues that if you route your changes through the recording, you get something strong.

That’s a real result. It just isn’t the unlimited one a four-word banner suggests — and to their credit, the paper draws the line itself rather than leaving it to a sceptical reader. It separates acquiring a resource (opening a file, allocating memory, spawning a process), which it tracks and can reverse, from emitting through it — the bytes actually written, the message actually sent — which is gone. Once data has left, the framework can only offer compensation the application author writes by hand, and the paper says plainly that its metatheory does not cover that. A location the system “cannot reify,” it states, “lies outside the boundary” and outside the theorem with it.

So what’s the actual achievement?

The proof.

Two ideas from programming-language theory — effects (what a computation does to the world) and coeffects (what a computation needs from the world) — get lifted out of the type system and into the runtime, unified into a single notion of context. And then the paper does the hard part: showing the guarantee still holds not just for one component in isolation, but for whole systems of components arriving, leaving, and interleaving in arbitrary order.

That last clause is where the difficulty lives. It is not very hard to make one plugin clean up after itself. It is quite hard to prove that any sequence of arrivals and departures, in any order, however many times, leaves you with exactly the state you’d have had if nothing had ever moved.

The paper is also honest about its ancestors. It names OSGi — the Java module system underneath Eclipse’s plugin architecture — as the closest precedent, and argues its own addition is inverse tracking plus asynchronous teardown. It discusses Erlang’s hot code reloading, which swaps code in a live system but requires hand-written state migration and doesn’t unload components or roll back their effects. It discusses dependency-injection frameworks like Spring and Guice, where wiring happens at initialisation and doesn’t react to later change. Anyone who has read a related-work section knows how rarely they’re this direct about what isn’t new.

Where it came from

The last thing worth knowing is that this isn’t a laboratory producing something from nothing.

The runtime being formalised is called Cordis, and it has been running inside an open-source chatbot framework called Koishi — built and maintained largely by one developer — for years before any of this was news. The paper’s own case study puts it at “over four years of development” and “over 4000 community-contributed plugins,” written by people who were not thinking about metatheory at all. That developer is a co-author.

So the shape of the story is: someone built a thing that worked, kept it working in the open for years, and then sat down with collaborators to work out precisely why it worked and what could be guaranteed about it.

The paper is careful about what that history proves, too. Its own threats-to-validity note concedes that the evidence “is drawn from a single ecosystem in a single host language,” can’t separate the paradigm’s merits from those of its TypeScript implementation, and is “observational rather than a controlled comparison.” Four thousand plugins is a good sign. It isn’t an experiment.

One caveat to carry away: the paper labels itself a preprint under active revision, not a peer-reviewed result, and says its contents may change substantially. Read it as a serious argument in progress rather than a settled one.

Disclaimer: Written by Human, improved using AI where applicable.

Cordis on Shane's Personal Blog