cordiverse/paper: the arXiv preprint behind the Cordis composability paradigm

What cordiverse/paper actually is, and who it is written for

The repository is a paper repository. Its top-level entries are .gitattributes and README.md, and the README opens with the title "A Programming Paradigm for Spatiotemporal Composability" followed by a link to arXiv:2608.25512 under cs.PL. There is no source tree, no package manifest and no build configuration. Anyone arriving from a package index expecting an installable artifact has the wrong repository.

The audience is narrower and more academic. The README frames the problem as one that shows up in plugin systems and self-evolving agent harnesses: software that must compose dynamically, where the formal foundations are described as underdeveloped. If your work involves loading and unloading components at runtime, and you have ever had to reason about whether removing a component leaves the host in a clean state, this is the problem statement the paper addresses. If you are writing an application and want a dependency to do that for you, the README points at Cordis, described as a meta-framework implementing the ideas, rather than at this repository.

Revertible effects and reactive coeffects: the two mechanisms

The paper separates dynamic composition into two orthogonal dimensions, and the naming is worth reading carefully because it inverts the usual association. Temporal composability is defined as the ability to completely revert a component's side effects upon removal. Spatial composability is the ability to declare and reactively manage inter-component dependencies. Time is about undo; space is about dependency structure.

The mechanism for the temporal half is the revertible effect. Every context transformation carries an inverse that the runtime holds. That is the whole idea: the runtime does not infer how to undo an operation, it keeps the inverse alongside it, so reversion is local to the component that performed the transformation. The mechanism for the spatial half is the reactive coeffect. Every context change is classified against a component's coeffect specification, and that classification drives the component's activation and deactivation. A component does not poll for its dependencies; changes to the context are matched against what it declared.

The two are then unified: the effect context and the coeffect context become a single context type, and every effect and coeffect is mediated through it. The README states that this mediation induces an observational equivalence up to which the effects of distinct components interleave without disturbing one another. That sentence is doing a lot of work, and it is the part a practitioner should interrogate first, because it is the claim that makes interleaving safe rather than merely concurrent. The README does not sketch the proof, so the arXiv text is where that has to be checked.

From one component to a system: the calculus and its metatheory

The paper packages the two mechanisms into a notion of a component and then gives a calculus of dynamic composition. The stated goal of the metatheory is to carry spatiotemporal composability from a single component to a whole system of interleaved components. That is the load-bearing step. A single component that can revert its own effects is a manageable engineering property; a system where many such components interleave, each activating and deactivating as the shared context changes, is where the interesting failure modes live.

The README does not reproduce the calculus rules or the metatheory, and it does not list theorems. What it gives is the abstract and the shape of the argument. If you need to know whether the observational equivalence holds under a particular interleaving pattern, or what the calculus assumes about inverse availability, the README is silent and the paper is the only source. Treat the README as an abstract with a citation block, which is effectively what it is.

Cordis is named as the implementation, not shipped here

The final paragraph of the abstract states that the ideas are implemented in Cordis, described as a meta-framework of spatiotemporal composability. Three pieces are named: a core library with effect tracking and coeffect resolution, a declarative component loader with configuration reconciliation, and hot module replacement.

Those three map onto the paper's dimensions in a way worth noting. Effect tracking and coeffect resolution correspond to the two runtime mechanisms. Configuration reconciliation and hot module replacement are the operational surface: reconciliation is what happens when a component's declared configuration changes, and hot module replacement is the most visible test of temporal composability, because swapping a module at runtime is exactly the moment where an un-reverted side effect becomes a leak.

What the README does not provide is any link to the Cordis codebase, any package name, any version, or any statement about how closely the implementation tracks the calculus. The repository is named cordiverse/paper, which suggests a cordiverse organisation, but the README never says where Cordis lives. That is the first thing to resolve if your interest is practical rather than theoretical.

Installing cordiverse/paper: there is nothing to install

There are no install steps in the README, because there is nothing to install. The repository contains a README and a .gitattributes file. If you want the paper, the README gives exactly one route: the arXiv link.

The only executable-looking content in the README is the citation block, which is BibTeX rather than code. If you need to cite the work, the README supplies the entry verbatim, including the eprint identifier and the primary class:

@misc{shi2026cordis,
  title         = {A Programming Paradigm for Spatiotemporal Composability},
  author        = {Shi, Yifan and Zhang, Wei and Cui, Tianyi},
  year          = {2026},
  eprint        = {2608.25512},
  archivePrefix = {arXiv},
  primaryClass  = {cs.PL},
  url           = {https://arxiv.org/abs/2608.25512},
}

The README adds a note above the abstract: the work is a preprint under active revision, the arXiv page always serves the latest version, and citations should be made accordingly. That note is the practical instruction. If you cite a specific revision, the README's own guidance is that the arXiv page is the moving target, so pin whatever version identifier arXiv gives you at the time you read it.

If you were hoping to run the calculus, you cannot. The README does not describe a reference implementation, a proof assistant formalisation, or a test suite. The only route to the ideas in executable form is Cordis, and the README does not say where to get it.

Where the paper stops being useful

The clearest limitation is scope. This is a preprint under active revision, by the README's own description. Anything you build on a specific revision carries the risk that the revision changes. For a paper whose central claim is a metatheorem about interleaving, a revision that adjusts the calculus or tightens an assumption can invalidate an implementation that was built against the earlier statement.

The second limitation is the gap between the calculus and any real runtime. Revertible effects require that every context transformation carry an inverse the runtime holds. That is a strong requirement, and the README does not discuss what happens when a transformation has no practical inverse, or when the inverse is more expensive than the original operation. Systems that talk to the outside world, write to a database, or send a network request are exactly where inverses are hardest. The paper's framing is about context transformations, which may sidestep this, but the README does not say so, and a reader coming from an I/O-heavy codebase should not assume the discipline transfers without work.

The third limitation is that the README is not a substitute for the paper. It contains an abstract, a citation and an acknowledgments section. If you want to evaluate the metatheory, the repository gives you no shortcut.

Alternatives: effect systems and dependency-injection containers

The closest established alternatives sit on either side of the paper's two dimensions, and neither covers both.

Algebraic effects and handlers, as found in languages like Koka and in libraries such as effect-ts or ZIO, give you a disciplined way to describe and interpret effects, and handlers can scope an effect's lifetime. The difference in approach is that handlers delimit and interpret; they do not require every transformation to carry an inverse held by the runtime. Undo is something you write into the handler, not something the runtime guarantees. If your problem is describing effects cleanly, an effect system is the more mature tool. If your problem is guaranteeing that removal reverts, the paper's revertible effects are addressing something the handler model leaves to you.

On the spatial side, dependency-injection containers and reactive frameworks handle declaration and reactivity. A DI container resolves dependencies and can rebuild a graph when configuration changes, which is close to what the paper calls reactive coeffects. The difference is the classification step: the paper classifies every context change against a component's coeffect specification to drive activation and deactivation, rather than resolving a graph once at startup or on an explicit refresh. Frameworks that rebuild on change get partway there; the paper's claim is a stronger, per-change discipline unified with the effect side through a single context type.

Neither alternative gives you the unification. That is the paper's contribution, and it is also why the paper is harder to adopt: you cannot drop it into an existing effect system or DI container without adopting the single context type that mediates both.

Maintenance, revisions and licensing

The repository is not archived, and the last push was on 2026-08-28. That is recent, but the commit history is not evidence of a maintained codebase, because there is no codebase. The README's own note that the preprint is under active revision is the more meaningful maintenance signal: expect the arXiv version to move.

On licensing, the repository listing shows no licence file. The README contains a citation block and an acknowledgments section but no licence statement. That matters if you intend to reuse text, figures or code from the paper, and it matters more if you intend to reuse anything from Cordis, whose licence the README does not mention at all. Check the licence on the arXiv page and on the Cordis repository separately before you rely on either. Nothing here is legal advice; the point is simply that the repository does not answer the question.

Upgrade cost is unusual for a paper repository. There is no dependency to bump. The cost is re-reading: if a revision changes the calculus, you re-read the affected sections and re-check any implementation that depended on them. The README's instruction to cite the arXiv page as the latest version means the burden of pinning falls on you.

Editorial conclusion

Read cordiverse/paper if you are designing a plugin host, an agent harness or any runtime where components are added and removed while the system runs, and you want a formal vocabulary for reversible side effects and dependency-driven activation. Do not clone it expecting a library: the repository holds a README and a .gitattributes file, and the README points to arXiv:2608.25512 for the actual text. Before building on it, verify three things: that the arXiv version you cite matches the revision you read, since the README calls it a preprint under active revision; that the Cordis implementation still matches the calculus, since the README does not state a version correspondence; and that the licence permits your use, because no licence file appears in the repository listing.

Frequently asked questions

Official sources

1. cordiverse/paper on GitHub
2. Issues
3. README