Spatio-
temporal
Composability.

Supports dynamic extension install, but true fine-grained live unloading of arbitrary executable code is absent — a process restart is still the coarse boundary. Teardown lives in a separate place from setup, making cleanup a discipline, not a structure.

OSes give temporal composability at process granularity; orchestrators give spatial composability at service granularity. But that is too coarse when composition happens inside one process — restarts destroy caches and partial work; services add network overhead.

Because teardown must undo setup, the inverse of a composed operation is the reverse composition of its inverses.

/* twisted composition (4) */
(f₁, g₁) ∘ (f₂, g₂) := (f₁∘f₂,  g₂∘g₁)

/* effect context (5): state + recovery accumulator */
∂Γ := Γ × (Γ → Γ)
   (γ, φ)  —  current state + prior-state recoverer

/* tracking (6): extend the accumulator with the inverse */
track(f, g)(γ, φ) = ( f(γ),  φ∘g )

/* recovery (9): run the accumulator, reset */
recover(γ, φ) = ( φ(γ), id )

A logical key resolves to a realm, then the realm resolves to a value (27). Isolate the same key differently per subtree — per workspace, session, account, or sandbox.

/* (28) get through realm indirection */
get(k)(ρ, σ) = σ( ρ(k) )
isolate(k, r)(ρ, σ) = ( ρ[k↦r], σ )

Easy to reason about, but invasive — threading state through every call.

An explicit first-class context mediates both mutation and dependency access.

(41) The target records exactly which provider identity should satisfy each requirement. Two providers may expose equal values yet be different lifecycles. Replacing a provider with a new instance therefore triggers a dependents' reload.

Multi-step activation yielding an inverse per step (47), enabling partial rollback if interrupted mid-activation.

(49) A failure adds no new inverse, but earlier steps still recover — transactional activation, not a try/catch.

inverse = identity
for each successful effect step:
    inverse = yieldedInverse ∘ inverse
return inverse

The armed guard makes disposal idempotent; child disposers compose into parents. Crucially, Cordis does not mechanically prove the inverse is correct — TypeScript trusts the author for that local obligation.

Config becomes the authoritative description of desired composition; reconciliation maps each change to the least disruptive fiber op.

The theory's Γ is bounded by what the runtime can exclusively control and restore.

Strategies: withholding (delay emission until local state commits) or compensation (delete / refund to restore application-level equivalence).

Exclusive binding perturbs dependents on every switch. A stable broker stands the capability to consumers while providers come and go behind it — for rolling updates and load balancing.

Dependency cycles leave components permanently inactive — detectable from declarations. Factor into smaller core + integration components, though bindings can grow quadratically.

Make context implicit while preserving semantics; compile effect iterators into state machines; make coeffect declarations part of the type system — enabling compile-time cycle detection and structural checks.

# from Eq. (37), literally
component:
  id: memory.hindsight
  requires: [ workspace.fs@1, persistence.sqlite@1 ]
  provides: [ memory.semantic@1 ]
  apply:
    - open database
    - start indexer
    - register memory provider
  # each atomic mutation yields its own disposer

The runtime should not accept a component as merely start() / stop(). It should mediate environmental effects so teardown is derived from setup.

capability: workspace.fs@1
policy:
  read:  [ /repo/** ]
  write: [ /repo/src/** ]
  deny:  [ /repo/.env ]

Policy is supplied by the context, not the provider. But per Section 6.3 this is not a sandbox for hostile code.

Build the precedence graph (60) before activation and detect cycles — so two plugins aren't silently inactive. The UI can explain the cycle and suggest a decomposition into session-core + bindings.

1. Effect ledger / inverse-first mutation API — every mutation returns its disposer.
2. Capability declarations — every component gets explicit requires and provides.
3. Provider identity in target state — track which instance a consumer committed against.
4. Four-state lifecycle — inactive / loading / active / unloading, plus failure.
5. Drain dependents before provider recovery — a kernel-level rule.
6. Iterated setup with rollback checkpoints — especially for self-generated extensions.
7. Desired-state reconciliation — the orchestrator changes config; the runtime derives transitions.
8. Transactional HMR / self-update — keep old code until the new version instantiates.
9. Context realms — for workspaces, rooms, accounts, sessions, sandboxes.
10. Interception metadata — as a generic policy / capability attenuation.

1. Load a provider, start a consumer.
2. Replace the provider while the consumer is active.
3. Verify the consumer drains before the old provider disappears.
4. Inject a failure mid-activation; verify restore.
5. Mutate two independent providers concurrently.
6. Unload one; verify the other's state remains.
7. Isolate the same capability into two workspaces.
8. Apply permission interception to one realm only.