A research artifact, not a package
The repository name is easy to misread. This is not the Cordis framework and it has no executable source. It contains a short README and an 88-page PDF titled A Programming Paradigm for Spatiotemporal Composability. The practical implementation lives in cordiverse/cordis, a separate TypeScript project. That separation matters: cloning this repository gives you an argument to evaluate, not a dependency to install.
The argument starts from a familiar weakness in plugin systems. A component can register event handlers, open resources, publish services, and depend on other components, but removing it safely is often harder than adding it. Hosts fall back to restarting a process, which discards unrelated in-memory state. The paper divides the problem into two dimensions. Temporal composability means a removed component's tracked changes can be reversed. Spatial composability means its requirements are declared and reevaluated as providers enter or leave the running system.
This vocabulary is the paper's first useful contribution. It separates cleanup from dependency wiring while showing why a real component lifecycle needs both. Framework authors can use that distinction even if they never adopt Cordis.
The model is more concrete than the title sounds
The paper turns the two ideas into runtime mechanisms. A revertible effect pairs a context change with an inverse, and the runtime accumulates those inverses for ordered cleanup. A reactive coeffect describes something a component needs. When the context changes, the runtime decides whether the component should activate, deactivate, or stay as it is. The two sides meet in a shared context and a component lifecycle represented by fibers.
The implementation section makes this easier to judge. Cordis routes context mutations through an effect primitive, records cleanup, resolves declared dependencies, and waits for dependents to shut down before removing their provider. A component whose dependency changes is unloaded and reloaded against a committed view. The loader adds declarative configuration reconciliation and hot module replacement, including rollback when a replacement fails. These are specific operational rules, not merely a slogan about modularity.
There is also a useful claim about local reasoning. If component authors create changes through the context, the host owns disposal ordering rather than relying on every plugin to maintain a distant uninstall routine. That is attractive in large plugin ecosystems, where one incomplete cleanup path can leave listeners, services, or state behind.
Koishi is evidence, but not a benchmark
The paper's case study is Koishi, a chatbot framework built on Cordis. It says the ecosystem has more than 4,000 community plugins and uses the same component ideas in both the server and browser console. Plugins can be disabled through an orchestrator, edited modules can be reapplied while unrelated state stays alive, and dependencies such as messaging adapters or database drivers can determine whether consuming plugins are active. That is meaningful evidence that the abstraction can support a large, independently authored ecosystem.
The authors are commendably direct about what this does not prove. Koishi currently uses Cordis v3, while the paper describes refined v4 semantics and a redesigned loader. The study covers one ecosystem in one host language. It is observational, with no controlled architectural comparison, measured runtime overhead, or developer-productivity result. The paper calls those measurements future work. Anyone choosing an architecture should treat Koishi as an existence proof, not a performance guarantee.
That gap is especially relevant because effect tracking, dependency notification, and reload ordering all add machinery. The formal model argues about correctness under its assumptions. It does not tell an operator what latency, memory cost, debugging burden, or failure rate to expect in a particular application.
The boundary conditions are the buying decision
The most important caveat is that not every side effect is reversible. The paper draws a boundary between tracked acquisitions and external emissions. Opening a resource can be paired with closing it, but bytes already sent over a network, mail already delivered, or a payment already made do not disappear when a component unloads. Withholding output until commit or writing a compensating action may help, but compensation uses an application-defined notion of recovery and is not covered by the same proof.
Security has a similar limit. Declared dependencies and context interception can restrict access through the framework, but they do not contain hostile code that can reach the host runtime directly. The paper explicitly requires an external sandbox, separate process, runtime, or container for untrusted components. A plugin marketplace cannot substitute Cordis dependency declarations for isolation.
Dependency compatibility is unfinished too. A matching key can connect a consumer to a provider whose interface has drifted or whose name collides with an unrelated service. Cordis currently uses package-manager peer dependencies, which relies on honest semantic versioning and usually resolves one version. Structural runtime compatibility is discussed as an open problem. Cycles are predictable but leave the involved components inactive, and breaking mutual dependencies into smaller integration components can increase configuration and cognitive load.
Very young repository, worthwhile paper
The repository was created on August 13, 2026 and last pushed that day. It has two commits, no tagged releases, no declared license, and both issues and pull requests are disabled. Its 2,243 stars show immediate attention, but there is no public maintenance queue here from which to judge response quality or revision cadence. The README also labels the work an actively revised preprint that may change substantially.
As documentation, the PDF is unusually detailed. It includes formal definitions, operational algorithms, implementation mapping, related work, practical discussion, and clear threats to validity. As a repository for adoption, it is incomplete: there is no source, build, changelog, citation file, or license grant.
Read it before designing a plugin runtime that must change without restarts. It offers a strong mental model and enough implementation detail to challenge an architecture. Then move to cordiverse/cordis, inspect the code and current API, and test the hard parts the proof does not erase: irreversible output, hostile extensions, version drift, and real operating cost.