On this page
Runtime Model๏
Reader Question๏
Which components own definition, compilation, execution, lifecycle, and governance?
Short Answer๏
Aether owns process-level runtime state and AethericFrame partitions it into worlds.
Within a frame, a Spellbook defines and compiles graph structure; a Conduit hosts one
execution scope; Meld resolves objects; Creations and SpellSpace enforce lifetimes;
frame-local DevOps state governs structural mutation and stale-resolution refusal.
Responsibility Split๏
Component |
Owns |
Does not own |
|---|---|---|
Aether |
Frames and process roots |
Application domain behavior |
AethericFrame |
World-local registries, posture, control plane |
Cross-frame linking |
Spellbook |
Bindings, compilation, one root conjure |
Arbitrary repeated roots |
Conduit |
Runtime scope, contracts, pools, creation front door |
Global process state |
Meld |
Lookup, validity gates, instance realization |
Structural registration |
Creations |
Live instances and teardown metadata |
Graph definition |
DevOps plane |
Mutation admission, dirty roots, validity |
Normal read-path resolution |
Core Flow๏
A spellbook binds objects and their addresses/lifetimes.
Conjure compiles and validates structural and resolution artifacts.
The resulting conduit becomes the caller's runtime scope.
Meld resolves through compiled creation contexts and creation stores.
Structural changes mark affected truth dirty so later resolution can refuse or rebuild.
Why This Design Is Strong๏
Responsibilities are separated by ownership and phase. Definition work does not leak into the hot resolve path, while mutation governance does not charge every reader a transaction cost.
Tradeoffs๏
The split introduces more named components than a small service locator. In return, each component has a narrower lifecycle and the system can reason about changes, scopes, and failures without one global container object doing everything.
Where to Go Next๏
Source entry points: