On this page
Preserve and Evolve a World๏
Reader Question๏
How can an application recover a configured world and deliberately promote a new version without conflating persistence with live mutation?
Short Answer๏
Use Crystallizer checkpoints for continuity across process death. Use MutationResearch, inactive index members, and a mediated notch for deliberate live evolution. A checkpoint rebuild and a hot version promotion are separate workflows with separate evidence.
Continuity Workflow๏
Activate/configure Crystallizer for a dynamic world.
Let runtime lifecycle events record structural twins.
Create and flush a checkpoint to local or caller-provided external custody.
On a fresh process, reload, preflight, restore, and inspect the report.
Evolution Workflow๏
Read current research residence, source, drift, and impact.
Preview candidate code without executing, binding, or recording it.
Bind the accepted version as an inactive member beside the live version.
Notch the index through the structural transaction path.
Meld to realize the selected version after validity handling.
Revert deliberately by notching the retained prior member back into selection.
Why This Design Is Strong๏
The system can distinguish a rehearsed candidate, a staged version, a promoted version, and a reconstructed world. Each state has a separate owner and evidence surface.
Tradeoffs๏
Continuity requires recordable configuration and code participation at rebuild. Live evolution requires custody, research history, staging, and transaction governance. The cost buys explicit state transitions rather than treating deploy/restart as invisible magic.
Where to Go Next๏
Evidence: