# 🔵 Expert examples

**38 saved lessons.** Follow their order or choose a topic that answers your question.

[Open the Expert guide](../../expert/index.md) · [All examples](../index.md)

<ul class="example-list">
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="pod boot the order is the product booting a pod. advanced 17-18 taught checkpoint and load as two verbs you call yourself. this is the operator&#x27;s version: one entry point that runs the whole restart flow in a fixed sequence. melder&#x27;s own contract line is the lesson title: &quot;contract (the order is the product)&quot; read that as a claim, because it is one. every step below is something you could call by hand. the value crystallizerbootstrap adds is not the calls - it is that they happen in this order, and the order encodes reasoning you would otherwise have to rediscover after a bad restart. the seven steps 1. activate the crystallizer (the persistence system comes up with it). 2. attach the external manager, when one is configured. 3. reload the profile&#x27;s local cache. an empty cache is tolerated. 4. pull the profile&#x27;s remote history when enabled and a manager is attached - then re-flush the pulled ids so the local cache actually holds them. 5. pull remote formations (mesh-aware boot). default-on when the attached manager carries the generic fetch+list lanes; legacy-only managers skip silently. 6. verify the chain. &quot;broken&quot; refuses loudly; anything else rides the report. 7. load the most recent checkpoint by exact ledger insertion order - not by timestamp. why the order is load-bearing local before remote (3 before 4) means a pod that cannot reach the network still boots on what it has. the re-flush inside step 4 is the part people miss: pulling remote history does not by itself put it in the local cache, so a pod that pulled and then lost the network would have come back empty. verify (6) sits before load (7) so a broken chain refuses instead of half-restoring a world. and insertion order rather than timestamp in step 7 means two checkpoints written in the same second still have one answer. the two refusal shapes, both deliberate broken chain -&gt; runtimeerror. loud. there is no correct partial restore of a broken lineage. no history at all-&gt; boots an empty world, `restored_checkpoint_id` is none. a first boot is not an error. that distinction is the whole difference between &quot;nothing to restore&quot; and &quot;the thing i was going to restore is damaged&quot;, and melder refuses to collapse them into one outcome. it is one-shot. bootstrap() consumes the object; calling it twice raises. same law as aetherconfigurationbuilder.build() (advanced 07) and create_rift() consuming its configuration (advanced 09). md.crystallizerbootstrap - with_profile, with_pull_remote, with_formation_reload, with_preflight_gate, bootstrap resolution configuration connections agent rooms &amp; codegen persistence &amp; restore research &amp; change concurrency"><span class="example-level">🔵 Expert · 01</span><h3><a href="01-pod-boot-the-order-is-the-product.html">Pod boot the order is the product</a></h3><p>BOOTING A POD. Advanced 17-18 taught checkpoint and load as two verbs you call yourself. This is the operator&#x27;s version: one entry point that runs the whole restart flow in a fixed…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Inspection&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="persistence mesh your code their lanes the asymmetry at the edge of your world, demonstrated rather than described. melder never speaks to your database - it calls your callables. so the interesting question is what happens when one of them is missing or broken, and the answer is deliberately different for writes and reads. writes degrade and count. a missing write lane is a silent no-op. a write lane that raises is swallowed and tallied. your local seal never fails because a network you do not own did. reads refuse. a missing read lane raises. &quot;a missing lane means unavailable, not empty&quot; - because an empty answer would be indistinguishable from &quot;your remote has nothing&quot;, and that is the one reply that must never be guessed. leniency without accounting is just quiet data loss. that is why the manager carries `upload_failure_count` and `store_failure_count` and puts them in `describe_external_persistence_manager()`. your handler is allowed to fail; you are not allowed to be unaware of it. and callables never enter the record. handlers live in a separate configuration and the description &quot;expose[s] handler presence flags, never callable objects&quot;, because executable code cannot be serialized into a world record. a recorded world stays code-free and portable, which is what lets it be restored somewhere your storage code has never run. local custody is never hostage to a network you do not own. expert 09 shows the same rule from the wiring side; this lesson is the failure side of it. externalpersistencemanagerconfiguration store/fetch/ list handlers, configure_external_persistence_manager, flush_checkpoint through a working and then a failing handler, reload_profile_from_external with no read lane, and the failure counters in the describe payload resolution configuration inspection persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 02</span><h3><a href="02-persistence-mesh-your-code-their-lanes.html">Persistence mesh your code their lanes</a></h3><p>THE ASYMMETRY AT THE EDGE OF YOUR WORLD, demonstrated rather than described. Melder never speaks to your database - it calls YOUR callables. So the interesting question is what happens when…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Inspection</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Lifetimes &amp; cleanup&quot;, &quot;Configuration&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="research sets lanes and residency mutation research - melder&#x27;s record of how a world changed, not what it currently is. everything up to here described a runtime. this describes its history. the shape mutationresearch the subsystem (same ladder as aether and crystallizer - you activate the config, then the subsystem; advanced 17 settled that it is 3-to-1 with nexus the exception) researchset one named body of history researchlane a track within it researchjournal the ordered record two enums, and they answer different questions lanestate open / joined / archived - can i still write here? lanetype development / experiment / production / test - what kind of work is this? a lane has both. state is lifecycle; type is intent. collapsing them would mean you could not have an archived production lane and an open one at the same time, which is exactly what a real promotion history looks like. lane type enforcement is a knob set_lane_type_enforcement(enabled) off, the types are labels. on, they are rules. melder ships the choice rather than assuming which one you are doing - a research set exploring a hypothesis and a research set tracking a production promotion chain want opposite answers. residency is the idea worth taking away. residence_of(spell_id) -&gt; lane name or none a spell lives in exactly one lane at a time. that is what makes &quot;where is this thing now?&quot; a question with one answer, and it is why promotion is a move rather than a copy. `heads()` gives you the current tip per lane; `walk(lane)` gives the ordered contents; `history(spell_id)` follows one spell across lanes. campaigns group work that belongs together across lanes: set_active_campaign / clear_active_campaign / campaign_view set one and subsequent records join it, so you can ask &quot;what did this campaign touch&quot; without threading an id through every call. ancestry is staged, then recorded. stage_ancestry(parent_spell_ids) -&gt; record_world_entry(...) you declare the parents before the entry that uses them. staging is explicit and clearable, so a half-built lineage is visible as staged-but-unrecorded rather than silently attached to the wrong thing. md.mutationresearch, md.researchset, md.lanestate, md.lanetype - lanes, residency, campaigns, ancestry resolution lifetimes &amp; cleanup configuration inspection agent rooms &amp; codegen persistence &amp; restore research &amp; change concurrency"><span class="example-level">🔵 Expert · 03</span><h3><a href="03-research-sets-lanes-and-residency.html">Research sets lanes and residency</a></h3><p>MUTATION RESEARCH - melder&#x27;s record of how a world CHANGED, not what it currently is. Everything up to here described a runtime. This describes its history. THE SHAPE MutationResearch the…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Lifetimes &amp; cleanup</span><span class="example-topic">Configuration</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="diffs are derived never stored derive a diff, three ways, and watch the answer change. version records are full objects; &quot;what changed&quot; is computed on demand and never written back. &quot;a verdict is an answer, not a fact the system remembers.&quot; a derived diff cannot go stale, because it did not exist until you asked. that is the whole argument for storing full objects and computing comparisons - a stored diff is a second copy of the truth that can disagree with the first. three grains ship, and they are genuinely different questions source the text - a rename is enormous structural the shape - a rename is invisible parts the members - which pieces moved this lesson runs the same pair through all three and prints what each one concluded, because the point is not that three names exist - it is that they disagree, on purpose. two defaults at two layers, and this trips people diffengine.diff_materials(...) defaults to &quot;source&quot; the codegen room&#x27;s research_diff pins &quot;structural&quot; for a spell pair (expert 30) the engine&#x27;s default is text; the room overrides it with its reasoning layer. same family, different default, because the room knows it is answering an agent and the engine does not. the registry is open. `register_strategy` is public surface, so &quot;what changed&quot; is extensible by you rather than fixed by the library - the engine is open/closed, and &quot;adding a grain means registering a strategy, never editing this class&quot;. and the engine never reaches into the crystallizer. it takes an injected material resolver, which is why this lesson can run the whole diff family over material it holds in its hand, with no recorded world at all. `diff()` resolves through custody; `diff_materials()` is the door for material you already have - unbound codegen output, for instance. mutationresearch.create_diff_engine, diffengine.list_strategy_names / diff_materials, all three shipped strategies over one pair, and the keyerror an unknown grain raises resolution agent rooms &amp; codegen persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 04</span><h3><a href="04-diffs-are-derived-never-stored.html">Diffs are derived never stored</a></h3><p>DERIVE A DIFF, THREE WAYS, AND WATCH THE ANSWER CHANGE. Version records are full objects; &quot;what changed&quot; is computed on demand and never written back. &quot;A verdict is an answer, not a fact…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="protocol crafter the tool that writes the one tool that writes to disk. every surface in this curriculum so far reads: viewers read, crystals read, diffs derive, research records. protocolcrafter is the exception, and its own docstring flags that in a heading: &quot;it writes to disk - the unusual part: most of this codebase reads source; this one modifies it.&quot; it generates protocol definitions from a live class or object - turning a concrete type into the structural interface that describes it - and then maintains those definitions inside your interface files. why this exists melder resolves by shape (beginner 17: protocols as shapes). so the protocol is the contract, and hand-writing one for a class you already have is transcription - exactly the work a machine should do, and exactly the work that silently rots when the class changes and the protocol does not. the design decision worth stealing: bounded updates. &quot;its updates are bounded: it rewrites a delimited region rather than a whole file, so hand-written code around the generated block survives regeneration.&quot; that single choice is what separates a usable code generator from one you run once and then never dare run again. a generator that owns whole files forces you to choose between regenerating and keeping your own edits. a generator that owns a delimited block lets both live in the same file forever. it is the same instinct as the withheld-section probe at advanced 15: be precise about the boundary of your authority, and say where it ends. the surface, in two groups craft - returns code as a string, touches nothing: craft_protocol_code craft_protocol_module_code_from_source_file craft_joined_protocol_module_code write - puts it on disk: write_protocol_module_from_source_file write_joined_protocol_module add_protocol_to_interface_file remove_protocol_from_interface_file the split is not a clean 1:1 pairing, and the real shape is better than a pairing would be. two of the writes do have craft twins - the ones that generate a whole module from a source file, and the joined variant. the two interface-file writes have no twin at all. that looks like a gap until you read their signatures: add_protocol_to_interface_file(path, protocol_code) the crafted code is the argument. you cannot add a protocol you have not crafted, because the crafted string is what you pass in. the preview is not a parallel verb you are trusted to remember to call - it is the input, and there is no route to the file that skips it. and the bounded-block rules are the rest of it. `add` refuses by name if that protocol is already present rather than appending a second copy, `remove` deletes one named block and leaves the rest of your file alone, and both return the updated contents so the result is inspectable rather than assumed. md.protocolcrafter.craft_protocol_code (twice, for determinism), add_protocol_to_interface_file including its duplicate refusal, and remove_protocol_from_interface_file - all against a temporary directory that removes itself resolution connections inspection persistence &amp; restore research &amp; change concurrency"><span class="example-level">🔵 Expert · 05</span><h3><a href="05-protocol-crafter-the-tool-that-writes.html">Protocol crafter the tool that writes</a></h3><p>THE ONE TOOL THAT WRITES TO DISK. Every surface in this curriculum so far reads: viewers read, crystals read, diffs derive, research records. ProtocolCrafter is the exception, and its own…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Connections</span><span class="example-topic">Inspection</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="two knobs and a terminator per rung the last two public names, and what they say about the whole configuration story the curriculum has been tracking since advanced 07. mutationresearchconfiguration has exactly two knobs: with_unrestricted_module_mutations(enabled) with_lane_type_enforcement(enabled) two. that is the entire configurable surface of a subsystem with 49 public methods, and the smallness is the point - the research plane records what happened; it does not need a policy engine to do it. compare aethericframeconfiguration&#x27;s fourteen (advanced 05): a frame is a world and needs a law book. a research set is a ledger and needs almost nothing. what the two knobs actually govern unrestricted_module_mutations - whether the plane will record mutations that reach outside a spell&#x27;s own module. off is the conservative posture. lane_type_enforcement - whether lanetype (expert 03) is a rule or a label. you met this on the researchset as a live setter; here is where the default comes from. that second one is worth noticing: the same switch exists in two places, at two scopes. the configuration sets the default for new sets; researchset.set_lane_type_enforcement overrides it per set. a knob at both scopes is a deliberate answer to &quot;is this a house rule or a per-experiment choice&quot; - melder says both. and the builder closes the configuration arc. advanced 17 measured nine public configuration objects carrying five different terminator sets. this builder is the most generous shape in that table, tied with the crystallizer&#x27;s: build() hand me the configuration finalize() ...frozen activate() ...and in force one terminator per rung. you choose where to get off the ladder, instead of always landing on rung one and climbing manually the way aetherconfigurationbuilder makes you. the ladder, one last time (and this is the fourth subsystem): aether caller activates the config (advanced 07) crystallizer caller activates the config (advanced 17) mutationresearch caller activates the config (here) nexus activate() finalizes it for you (advanced 08) three to one. caller-driven activation is the house rule and nexus is the exception - which is worth knowing before you meet a fifth subsystem and have to guess. and the fourth root has caught up. nexus was once the one root of four with no builder at all - its callers built the configuration by hand while every other root handed one over. it now carries the same three exits, so the generosity table above is no longer lopsided. what has not changed is the two-bits rule: the builder&#x27;s `activate()` marks the configuration active, and you must still pass it to `nexus.activate(...)`. two objects, two bits. the exits are one-shot, which is the point of a builder. each exit transfers ownership and consumes the builder; a second exit raises. that is what makes a builder different from a config you keep poking - there is exactly one owner at each step, and the handoff is the moment ownership moves. and `build()` earns its place on this root. the builder mirrors only the one knob almost everyone sets; the configuration carries a far wider `with_*` surface (frame allow/deny lists, tokens, nested rift policy). `build()` is the exit that hands you back something still mutable so you can reach the rest. a frozen-only builder would have made the wide surface unreachable through it. md.mutationresearchconfiguration, md.mutationresearchconfigurationbuilder, md.nexusconfiguration, md.nexusconfigurationbuilder resolution configuration connections agent rooms &amp; codegen persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 06</span><h3><a href="06-two-knobs-and-a-terminator-per-rung.html">Two knobs and a terminator per rung</a></h3><p>THE LAST TWO PUBLIC NAMES, and what they say about the whole configuration story the curriculum has been tracking since advanced 07. MutationResearchConfiguration has exactly TWO knobs:…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="the codegen room agents writing code the codegen room - where an agent writes code that becomes part of a running world, and the gate it has to get through first. this is the only room kind where the caller supplies executable source, so it is the only one that has to answer &quot;may i&quot; before &quot;did it work&quot;. the default posture is deny, and the denylist is the threat model written down. a codegen room with no widening projection ships with imports off entirely and thirteen builtins refused by name: __import__ breakpoint compile dir eval exec getattr globals input locals setattr delattr vars read that list as a document rather than a setting. every entry is a door out of the namespace contract: `eval`/`exec`/`compile` execute text the gate never saw, `__import__` bypasses the import rules, `getattr`/`setattr`/`vars`/`dir` reach attributes by computed name, and `globals`/`locals` hand back the environment itself. somebody enumerated the ways out and wrote them down where you can read them. a refusal is a value, and it names the offender. `validate_codegen` returns a payload, not an exception and not a bare boolean: {&quot;accepted&quot;: bool, &quot;frame_name&quot;: str, &quot;reason&quot;: str, &quot;validation_issues&quot;: (str, ...)} rejected source comes back as `accepted: false` with a message that names the specific thing - &quot;builtin &#x27;eval&#x27; is not allowed in this codegen mode&quot; - because a bare false would force you to re-run validation with different instrumentation just to learn why. the chain is ordered and it short-circuits. syntax is checked first (a parse failure never reaches a gate), then seven strategies run in a fixed sequence and the first refusal returns immediately: ast_structure -&gt; import_policy -&gt; builtin_policy -&gt; name_resolution -&gt; attribute_access -&gt; reflection_policy -&gt; recursive_control so `validation_issues` is normally one issue: the first gate that objected, not an audit of everything wrong. fix it and re-ask - the next answer may well name a different gate. and the order is observable, which is why it is worth knowing rather than guessing: `eval(&#x27;1 + 1&#x27;)` is refused by builtin_policy, which sits before name_resolution, so you get the builtin message rather than an unresolved-name one. read `recursive_control` twice. it is last in the chain and it exists because generated code that generates code is how a bounded system stops being bounded. someone thought about an agent escaping its sandbox by writing a smaller one inside it. validation runs before the environment exists, and that ordering is the point. the gates read the ast, not a live namespace. the execution environment has not been built when they run - and building it to find out whether building it was allowed &quot;would be exactly the escape the gate exists to prevent&quot;. that is why `validate_codegen` is a separate verb rather than a flag on execute: you can learn a boundary without approaching it. and melder does not claim this is a proof. in its own words, the checks reject obvious violations, because &quot;static analysis of python cannot be exhaustive, so the validation chain is defence in depth alongside the namespace denylists and the acl posture, not a proof of safety on its own&quot;. three layers, named, with the honest limit stated. a system that claimed a guarantee here would be lying, and the willingness to write that down is worth more than the claim. the room overrides a third property. advanced 11 found static and capability each swap two - `command_system` (what you may do) and `frame_viewer` (what you may see). codegenriftspace adds `codegen_system`: what you may make. do / see / make, each by handing over a different class rather than guarding a shared one. validate_codegen driven against accepted source, a denied import and a denied builtin; the validation payload shape; riftspace.space_kind / command_system / frame_viewer / codegen_system; list_supported_command_methods resolution configuration connections inspection agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🔵 Expert · 07</span><h3><a href="07-the-codegen-room-agents-writing-code.html">The codegen room agents writing code</a></h3><p>THE CODEGEN ROOM - where an agent writes code that becomes part of a running world, and the gate it has to get through first. This is the only room kind where the caller supplies EXECUTABLE…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="research is graduated by room how an agent reaches mutation research - and the discovery that access to it is graduated by room kind, exactly the way the conduit surface was in advanced 11. measure the three rooms and the pattern is unmissable: static room 0 research verbs capability room 21 research verbs codegen room 34 research verbs and the split is not arbitrary. compare the two that have any: capability-only verbs: none codegen-only verbs: 13 codegen is a strict superset. so the question is only: which 13 does it add? every one of them is a write. shaping lanes research_create_lane, research_attach, research_detach, research_join, research_archive campaign state research_set_campaign, research_clear_campaign ancestry staging research_stage_ancestry, research_clear_staged_ancestry composition research_group_register, research_group_recompose candidates research_preview, research_synthesize the law, stated plainly: a capability room can read the entire research record and cannot change one thing in it. only a codegen room can shape history. that is the same shape as advanced 11 one level up. there, static could reuse an existing spell but not create one; capability could create. here, capability can read the whole record but not write it; codegen can. the library applies one authority idea to two different planes, and in both cases it does it by absence - the verb is not on the class, it is not a guard that refuses. why that particular line reading history is safe: it cannot mislead anyone else. writing history is not - a lane you archived, an ancestry you staged, a group you recomposed all change what the next reader concludes. so the room that may fabricate code is also the only room that may restate the past, and both powers arrive together rather than separately. and the pair that makes it worth having research_preview what would this do? validate_codegen am i permitted to do this? (lesson 07) two independent &quot;would this work&quot; questions, both answerable without acting. most systems make an agent choose between acting blindly and not acting at all. and a verb has three states, not two. it can be absent (static has no research surface at all), present but refusing (the room carries it, the research root is not up, and the call raises a teach-grade runtimeerror), or working. the command path takes a non-constructing peek at the root precisely so that asking for research never boots one behind your back - and someone who asked deserves an error rather than an empty answer that reads like &quot;nothing was recorded&quot;. collapsing those two into one reply is how a reader concludes a world has no history when what it has is no root. the research_* gradient across static / capability / codegen rooms computed off the live surfaces; read-vs-write as the dividing line; and research_heads driven from a capability room both before and after mutationresearch is activated agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🔵 Expert · 08</span><h3><a href="08-research-is-graduated-by-room.html">Research is graduated by room</a></h3><p>HOW AN AGENT REACHES MUTATION RESEARCH - and the discovery that access to it is GRADUATED BY ROOM KIND, exactly the way the conduit surface was in advanced 11. MEASURE THE THREE ROOMS AND…</p><div><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Persistence &amp; restore&quot;]" data-search="getting data into your database put your world in your own database - and notice what melder does not do to get it there. this wires a real mesh, seals a real checkpoint, and watches the bytes arrive. melder never imports your database. the whole external lane is four callables you write: store(kind, profile_name, unit_id, payload) -&gt; none fetch(kind, unit_id) -&gt; payload | none list_units(kind, profile_name) -&gt; iterable of ids delete(kind, unit_id) the contract says it plainly: &quot;one callable, one table with a kind column, any db stack - melder never imports it.&quot; there is no driver, no dialect, no connection string anywhere in the library. `kind` is &quot;checkpoint&quot; / &quot;formation&quot; / &quot;emission&quot;, so one table with a kind column carries the entire mesh if you want it to. callables live outside the record, and that is a law with a reason. handlers go in a separate configuration object, and the record &quot;expose[s] handler presence flags, never callable objects&quot;. why: executable code cannot be serialized into a world record, so a recorded world stays code-free and portable. a record that embedded your storage code would only be restorable somewhere that code already ran. an empty configuration will not freeze, on purpose. upload-on-flush defaults true, so a configuration with no write handler is incoherent - it promises to upload with nothing to upload through. a read-only deployment must therefore say so out loud by disabling upload-on-flush. the default refuses to let you be vague. seal-then-ship is one verb with two guarantees, and only one of them is yours. `flush_checkpoint` does the local seal and the remote push, and the remote leg is lenient by default: a successful return proves the local seal and nothing about your database. so this lesson asserts the local seal and only reports what the mesh saw - because asserting the remote would be teaching you to trust the one half the return value does not cover. that is the same rule from the other side: local custody is never hostage to a network you do not own. and two describe doors, which is not redundancy describe_external_persistence_manager() what is wired describe_external_interface() what the contract is an operator debugging a mesh needs the first; someone implementing handlers needs the second. neither performs a network call. externalpersistencemanagerconfiguration with real store/fetch/list_units handlers, configure_external_persistence_manager, create_checkpoint / flush_checkpoint through the mesh, both describe doors, and the absence of any sync verb resolution configuration connections inspection persistence &amp; restore"><span class="example-level">🔵 Expert · 09</span><h3><a href="09-getting-data-into-your-database.html">Getting data into your database</a></h3><p>PUT YOUR WORLD IN YOUR OWN DATABASE - and notice what melder does NOT do to get it there. This wires a real mesh, seals a real checkpoint, and watches the bytes arrive. MELDER NEVER IMPORTS…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Inspection</span><span class="example-topic">Persistence &amp; restore</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="deep overrides paths through a graph overrides when the graph is deep. advanced 19 taught the three targeting forms - path, *unique, **broadcast - on a shallow graph where the difference between them is mostly convenience. this is the same grammar at depth four, where it stops being convenience and starts being the only way to say what you mean. a path is a chain of socket names, not a type &quot;gateway&gt;upstream&gt;credentials&quot; each hop is the parameter name on the class at that level. you are walking the constructor signatures, not the class hierarchy, and that distinction is the whole lesson: two sockets of the same type at different depths are different addresses. what depth changes 1. ambiguity becomes the normal case. on a two-node graph `*credentials` is exact because there is one. at depth four the same class appears on several branches, `*` starts refusing, and you either name the path or mean `**`. 2. you can replace a branch, not just a leaf. a path that stops half way swaps the whole subtree underneath it - everything that node would have built is replaced by the object you handed in. that is the difference between patching a value and grafting a different world in. 3. precedence stops being theoretical. give an exact path and a broadcast that both cover one socket and the exact path wins. specificity beats reach, which is the only rule that lets you say &quot;all of them except this one&quot; in a single call. 4. a wrong path refuses and names itself. it does not silently apply to the nearest match and it does not no-op. at depth four a typo is otherwise invisible, so the refusal is the feature. the house rule underneath all of it every one of these is the never-substitute law again: melder would rather refuse than guess which socket you meant. advanced 19 proved it on counts; this proves it on addresses. conduit.meld(override=...) with multi-hop paths, branch replacement, path-beats-broadcast precedence, and the refusal on an unresolvable path resolution research &amp; change concurrency"><span class="example-level">🔵 Expert · 10</span><h3><a href="10-deep-overrides-paths-through-a-graph.html">Deep overrides paths through a graph</a></h3><p>OVERRIDES WHEN THE GRAPH IS DEEP. Advanced 19 taught the three TARGETING FORMS - path, *unique, **broadcast - on a shallow graph where the difference between them is mostly convenience.…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="pointing a rift at your own frame ar onto your own world. advanced 09 built a rift and deliberately stopped short of targeting - it said so in its own text, because until 2026-08-03 the capability was genuinely unreachable from `import melder`. this is the lesson that finishes it. the chain, and every link is a refusal point 1. posture book.configure_aether_frame(rift_enabled=true) 2. publish book.conjure() -&gt; descriptor truth exists 3. allow config.with_allowed_target_frame_names([...]) 4. enable nexus.activate(config) -&gt; the rift domain is live 5. create nexus.create_rift(...) -&gt; a rift with one room 6. attach rift.create_frame_link(frame_name) attachment is two-party consent, and that is the whole lesson step 6 runs two independent gates, owned by two different parties, in this order (`rift.create_frame_link`): a. the observer&#x27;s policy nexus._validate_target_frame_names denied_target_frame_names - deny is checked first and wins allowed_target_frame_names - and it is not empty by default b. the world&#x27;s posture _validate_target_frame_runtime_requirements rift_enabled=true on the target frame - always ai_native_enabled on the target frame - codegen rooms system_state == dynamic - codegen rooms neither side can grant alone. the nexus says which worlds it may ever reach; the frame says whether it consents to being read. a perfectly postured frame that is not on the allow-list refuses, and an allow-listed frame with no posture refuses. both refusals appear below, because seeing only one of them teaches half the model. the default allow-list is `(&quot;default&quot;,)` - not empty that is the detail that surprises everyone, including whoever wrote the first draft of this lesson. an empty allow-list would mean &quot;no restriction&quot; (the check is skipped when it is falsy). melder ships a one-name list instead, so a fresh nexus can target exactly one conventionally-named world and every other world must be named deliberately. default-deny, expressed as data rather than as a flag. and it only governs foreign worlds. nexus-managed frames skip gate a entirely - a nexus does not need to put itself on its own allow-list. there is also a budget, and it is nexus-wide allow_multiple_target_frames default false max_target_frame_count default 1 target frames are ref-counted across rifts, so two rifts attaching two different worlds spend two of the budget, not one each. attach a second world with the defaults in place and you get &quot;multiple target frames are disabled.&quot; - which is a budget refusal, not a policy one. why rift_enabled defaults false, and should it is the frame&#x27;s opt-in to being observed. a world does not become inspectable because something else decided to look at it. you say so, once, before the frame settles - and after conjure the posture is frozen, so a world&#x27;s observability is fixed for its whole life. the part worth sitting with melder does not check permissions when the ar asks a question. it checks them when the ar attaches, and then never again. attachment is the authority boundary; everything after it is reading a world that already agreed to be read. and the order is not negotiable. posture must precede conjure, because conjure freezes it. conjure must precede attach, because attach requires descriptor truth. get it wrong and you get a refusal that names which link broke, not a mysterious empty view. configure_aether_frame(rift_enabled=..., ai_native=...), with_allowed_target_frame_names, with_multiple_target_frames, with_max_target_frame_count, nexus.create_rift, rift.create_frame_link, both gates resolution configuration connections inspection agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🔵 Expert · 11</span><h3><a href="11-pointing-a-rift-at-your-own-frame.html">Pointing a rift at your own frame</a></h3><p>AR ONTO YOUR OWN WORLD. Advanced 09 built a Rift and deliberately stopped short of targeting - it said so in its own text, because until 2026-08-03 the capability was genuinely unreachable…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Lifetimes &amp; cleanup&quot;, &quot;Configuration&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;]" data-search="the codegen loop end to end the codegen loop, actually run. expert 07 introduced the room and named its three verbs. this drives them: an agent asks permission, writes code into a named world, and reads back what it did. the loop validate_codegen(code, frame_name=...) may i? execute_codegen(code, frame_name=...) do it materialize_codegen(...) make it durable a refusal is a return value, not an exception. `validate_codegen` hands back a `codegenvalidationresult`. rejected code does not raise - and on the execute path a rejected validation returns a validation-failed `codegenexecutionresult` without ever reaching compile or exec. an agent reads a verdict; it does not catch one. (exceptions are reserved for malformed requests: empty code or an empty frame name raise `valueerror`. bad input raises, bad code reports.) validate is a separate verb, and that is the whole design. an agent can ask &quot;would this be permitted&quot; without running anything. and `execute_codegen` validates first anyway - the invariant is &quot;validation runs before execution on the execute path&quot;, so the separate verb buys you the answer early, never a way around it. every other safe-execution story collapses those into one call and forces you to attempt the thing to learn whether you were allowed to attempt it - which means the only way to discover a boundary is to cross it. what `validate` actually answers not &quot;is this good code&quot;. it answers &quot;does this code stay inside the posture this room was granted&quot;, against seven strategies: ast_structure, import_policy, builtin_policy, attribute_access, name_resolution, reflection_policy, recursive_control. read `recursive_control` twice. it exists because generated code that generates code is how a bounded system stops being bounded. someone thought about an agent escaping its sandbox by writing a smaller one inside it. the room remembers the source, and it pushes memory is not a describe-door you pull from the command system - it is `room.memory_system`, a `riftmemorysystem`, and you subscribe: room.memory_system.register_memory_callback(fn) -&gt; subscription id `memory_enabled` is literally &quot;does anyone have a callback registered&quot;, so emission costs nothing until something is listening. a paraphrase would be useless afterwards anyway - the question you ask later is always &quot;what exactly did it write&quot;. and the record is one per successful top-level call. two details make that precise, and both matter: - successful. a refused command does not emit. memory is a log of what happened, not of what was attempted. - top-level. the command system keeps a nested call-depth counter precisely to suppress duplicate emission when one public command calls another internally. you get the call you made, not the call tree underneath it. frame_name is required on both. generated code has to land in a named world and there is no sane default for that - a codegen call that guessed its target frame would be the worst possible bug. codegencommandsystem.validate_codegen / execute_codegen / research_preview, the codegenvalidationresult / codegenexecutionresult verdicts, and riftspace.memory_system callbacks. materialize_codegen is described here, not called - the third rung is a separate decision and expert 26 takes it; running is not keeping. lifetimes &amp; cleanup configuration inspection agent rooms &amp; codegen research &amp; change"><span class="example-level">🔵 Expert · 12</span><h3><a href="12-the-codegen-loop-end-to-end.html">The codegen loop end to end</a></h3><p>THE CODEGEN LOOP, ACTUALLY RUN. Expert 07 introduced the room and named its three verbs. This drives them: an agent asks permission, writes code into a named world, and reads back what it…</p><div><span class="example-topic">Lifetimes &amp; cleanup</span><span class="example-topic">Configuration</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="one workshop many worlds one codegen room, several worlds. expert 11 attached a rift to a frame; 12 ran the loop against one. this is the shape you actually end up with: a single workshop wired to several frames, each holding different objects, with the agent choosing per call which world it is writing into. this is where `frame_name` stops being a nuisance in 12 it looked like ceremony - one room, one frame, why type it. here the room can reach three worlds that hold different bindings, and `execute_codegen(code, frame_name=...)` is the only thing deciding which one the code lands in. a default would not be a convenience, it would be a coin flip with side effects. attachment is per frame and each one is its own decision rift.create_frame_link(&quot;billing&quot;) rift.create_frame_link(&quot;catalog&quot;) two calls, two gate checks. a rift does not acquire a world by being near it, and there is no &quot;attach to everything&quot; verb - because there is no honest way to ask for that. and multi-frame is off by default, in two separate knobs with_allowed_target_frame_names([...]) the observer&#x27;s policy with_multiple_target_frames(true) may there be more than one with_max_target_frame_count(3) how many, across the nexus the boolean and the count are not redundant: the first decides whether the plural case is permitted at all, the second bounds it. shipped defaults are false and 1, so this whole lesson is a deliberate opt-in - and the cap is spent nexus-wide because target frames are ref-counted across every rift, not per rift. the frames are still walled. advanced 02&#x27;s law does not soften because one observer can see several worlds: `billing` and `catalog` hold their own bindings, their own singletons, their own posture. the workshop is a room with several windows, not a room that merged the buildings. what the agent actually gets rift.list_accessible_non_nexus_frame_names() the rift asks which worlds it may target, and the answer runs both of expert 11&#x27;s gates - nexus allow/deny policy and per-frame posture, filtered by this rift&#x27;s space type. so it answers exactly &quot;what would attach if i tried&quot;. an agent does not have to guess and does not have to probe by attempting. caveat, stated plainly: that method and its nexus-level twin are both marked `internal` in their own docstrings. the capability is real and it is the best aix door in the subsystem, but it has no public marking yet - recorded as a finding, not taught as surface. and the posture bar is per frame too. a codegen room needs rift_enabled and ai_native and dynamic on every frame it targets. one qualifying world does not qualify its neighbours. several postured frames, the nexus target-frame policy and budget knobs, one codegen rift with several frame links, validate_codegen / execute_codegen once per frame through the one room, and the accessible-frames enumeration registration configuration connections agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🔵 Expert · 13</span><h3><a href="13-one-workshop-many-worlds.html">One workshop many worlds</a></h3><p>ONE CODEGEN ROOM, SEVERAL WORLDS. Expert 11 attached a rift to a frame; 12 ran the loop against one. This is the shape you actually end up with: a single workshop wired to several frames,…</p><div><span class="example-topic">Registration</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="compositions a subsystem as one unit compositions - naming a set of spells as one thing, and then asking questions about the thing instead of about its members. expert 03 taught residency: a spell lives in exactly one lane. that answers &quot;where is this one&quot;. it does not answer &quot;what is our billing subsystem&quot;, because a subsystem is not a spell - it is a set of them that someone decided to treat as a unit. the eight verbs, and two different splits run through them split one - by authority (which room may call it) organize (codegen rooms only - these write) research_group_register(member_spell_ids, lane=..., reason=...) research_group_recompose(previous_group_id, add=..., remove=...) read (capability rooms get these too) research_group_view(group_id) research_group_diff(left, right, strategy=...) research_group_impact(group_id) research_group_footprint(group_id) research_group_drift(group_id) research_group_history(group_id, campaign=...) six reads, two writes. that is expert 08&#x27;s law one grain up: a capability room can read the entire composition record and cannot change one thing in it. only a codegen room may restate what a subsystem is - because restating it changes what the next reader concludes about work nobody has redone. split two - by dependency (what the read has to reach) the six reads are not the same kind of question, and finding this out the hard way is the reason this lesson exists in its current form. three answer from the research record alone: view the roster and its lane joins history the journal story diff two rosters, plus lane-evidenced version moves three are foresight reads that join research truth to custody material, and they reach through the crystallizer to do it: footprint the physical module shadow impact the union blast radius and closure math drift recorded-vs-disk, narrowed to the footprint a foresight read with no live crystallizer refuses. it does not return an empty report, and melder says why in the message: &quot;foresight reads need the record - activate the crystallizer before asking for source, impact, or module graphs.&quot; never- substitute, on a read path. and the two absences are different, which is the subtle part instrument off -&gt; refusal (no crystallizer: cannot answer) instrument on, nothing to read -&gt; data (members with no custody crystal come back under `unknown_custody_members`) &quot;i cannot answer&quot; and &quot;the answer is none&quot; are not the same fact, and melder refuses to spell them the same way. the id is the membership, not a serial number `group_id` is a sha256 over the sorted, deduped member list. three consequences follow, and none of them are cosmetic: - a composition is a set. input order and duplicates cannot change its identity, because they are canonicalised away before the hash. - the same roster is the same composition. not a copy of it - it. so re-declaring an unchanged set refuses as a rediscovery and the error names the lane already holding it. you cannot accidentally end up with two names for one subsystem. - a recompose that resolves back to the previous roster refuses for exactly the same reason. remove-then-re-add is a no-op, and melder will not record a no-op as history. recompose succeeds the old one, it never edits it a new node is registered with `parent_group_ids=[previous]`, in the same lane, and the previous composition is untouched. forward-only: the old answer stays exactly as true as it was, and the timeline is walkable instead of lossy. what comes back is a payload, not a node both writes return `node.describe()` - a plain dict carrying `node_type`, `group_id`, `member_spell_ids`, `parent_group_ids`, `author`, `reason`, `campaign`, `created_at`, `metadata`. detached and plain-value, so holding one cannot mutate the record. and the join that makes it useful research_group_history(group_id, campaign=...) history is when. campaign is why. passing both is the where-by-when join - &quot;how did this subsystem change during that effort&quot; - which is the question you actually have during a review, and the one you cannot ask if a set is only ever a list you kept in your head. impact is lifted too. `research_impact` on a single spell names the groupedresearchnode subsystems it touches under `affected_compositions`. blast radius stopped being a list of files and became a list of things with names. the eight research_group_* commands across a codegen room and a capability room, the read/write line between them, and the record/foresight line inside the reads resolution inspection agent rooms &amp; codegen persistence &amp; restore research &amp; change concurrency"><span class="example-level">🔵 Expert · 14</span><h3><a href="14-compositions-a-subsystem-as-one-unit.html">Compositions a subsystem as one unit</a></h3><p>COMPOSITIONS - naming a SET of spells as one thing, and then asking questions about the thing instead of about its members. Expert 03 taught residency: a spell lives in exactly one lane.…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="campaigns the why that rides along campaigns - the why, carried without anyone remembering to carry it. expert 14 built a subsystem and left one argument dangling: `research_group_history(group_id, campaign=...)`. this is what goes in that slot, and why the slot is worth having. a campaign is a stamp that crosses lanes. lanes are where work lives; a campaign is which effort it belonged to, and one effort routinely touches several lanes, several subsystems, and several agents. nothing else in the record can express that, because everything else is organized by place. the surface, and it splits the same way set (codegen rooms only - these write) research_set_campaign(campaign) research_clear_campaign() read (capability rooms get this too) research_campaign_view(campaign) the one thing to actually learn here campaign=none does not mean &quot;no campaign&quot;. it means inherit. pass nothing and the record takes the ambient stamp. to record something with no campaign at all you must clear the ambient one first. that reads like a trap until you see what it buys: campaign membership never depends on an agent remembering to pass an argument on every call, across a session that might be thousands of them. attribution defaults to true rather than to blank. an explicit campaign still wins over the ambient one, so the default is a default and not a cage. and `none` means the opposite thing on the read side register_group(campaign=none) -&gt; inherit the ambient stamp group_history_view(campaign=none) -&gt; unfiltered, every effort same word, same type, same argument name, opposite meaning - and melder&#x27;s own docstring calls the difference out rather than leaving you to find it. it is right both times: a write that names no effort belongs to the one in progress, while a read that names no effort wants everything. attribution defaults to specific; queries default to broad. guessing one rule for both is how you end up reading a filtered history and thinking it was the whole story. and it rides exactly four seams, not everything the ambient stamp is applied by the root facade: `record_world_entry`, `record_promotion`, `register_group`, `recompose_group` - every dynamic bind, staged bind, notch, and composition write. the room&#x27;s organizational verbs (`research_create_lane`, `research_attach`, `research_archive`) delegate straight to the research set and are unstamped. moving furniture is not part of an effort&#x27;s story unless you say so. write/read agreement, and it is a law (bug-047) an empty campaign is refused on the write side for one stated reason: `campaign_view` refuses it on the read side. a public write may never create a record the public query api cannot reach. that is the never-substitute law wearing a different hat - melder would rather refuse your write than let you produce a fact nobody can ever ask about. what the view answers {campaign, nodes, transitions, lane_names} transitions and nodes are not the same set, deliberately. every stamped journal entry is a transition; only four acts contribute a node (registered, staged, group_registered, group_recomposed). a campaign of pure organizational moves yields transitions and an empty node list - that is correct, not a gap. and the sequence is the journal&#x27;s order, not a lane walk. lane iteration would tie-break same-millisecond ulids on their random component, so the story would reorder itself between runs. a history that is not reproducible is not a history. research_set_campaign / research_clear_campaign / research_campaign_view, ambient inheritance through research_group_register and research_group_recompose, and research_group_history(campaign=...) registration resolution agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🔵 Expert · 15</span><h3><a href="15-campaigns-the-why-that-rides-along.html">Campaigns the why that rides along</a></h3><p>CAMPAIGNS - the WHY, carried without anyone remembering to carry it. Expert 14 built a subsystem and left one argument dangling: `research_group_history(group_id, campaign=...)`. This is…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="rewiring a running world changing the wiring while the world runs. a dynamic world can gain a relationship after it is built: two conduits link, one pulls a spell it does not own into its contract, and the next meld resolves through the new edge. three verbs, no ceremony. owner.link(borrower) borrower.add_spell_to_contract(spell_id=..., conduit=owner, ...) borrower.meld(...) each verb is complete in itself. there is no window to open, no session to hold, nothing to commit afterwards. a structural verb does its own bookkeeping and either finishes or refuses - so the only thing a caller has to get right is the order, and the order is just dependency order. sharing is a pull, and the direction is the common mistake borrower.add_spell_to_contract(spell_id=s, conduit=owner) reads &quot;borrower pulls s from owner&quot;, and the conduit named in the call must own s. an owner trying to push its spell into someone else&#x27;s contract is refused with &quot;not owned by this conduit&quot;. the receiver asks; the provider does not give. the order of operations, per dependency edge 1. conjure the provider conduit 2. conjure the consumer conduit 3. link() - only after both exist 4. the consumer pulls the provider&#x27;s spell into the contract 5. meld - this completes the late binding for that world chains assemble edge by edge. skip step 5 on a middle world and its consumer constructs with its python default instead of the melded object - that is a usage error with a visible symptom, not a runtime gap. why you do not have to think about concurrency here melder serializes structural change internally, at a grain fine enough that independent work overlaps: two agents adding to the same spellbook do not wait on each other, while an operation that changes what that spellbook is excludes them both. none of that vocabulary belongs in your code. if it ever shows up in a traceback you will get the blocking holder named, not a hang. and a world can be told it does not do this `link()` asks the frame posture first, and the posture gate answers for both of the obvious cases: a dynamic world with disable_linking=true -&gt; refused an ordinary static world -&gt; refused both get the same sentence - &quot;linking is disabled for the current frame posture.&quot; - and that surprised the author of this lesson, who expected the static world to complain about dynamic mode. it does not, because an unconfigured non-dynamic frame is already &quot;not allowed to link&quot; as far as the posture gate is concerned; the separate dynamic-mode message sits behind that gate and only surfaces when the posture passes and the conduit was nevertheless conjured non-dynamic. the lesson: the message names the gate that refused, not the property you were thinking about. two different worlds, one gate, one sentence. md.spellbook.bind / conjure / configure_aether_frame, conduit.link / add_spell_to_contract / meld registration resolution configuration connections agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🔵 Expert · 16</span><h3><a href="16-rewiring-a-running-world.html">Rewiring a running world</a></h3><p>CHANGING THE WIRING WHILE THE WORLD RUNS. A dynamic world can gain a relationship after it is built: two conduits link, one pulls a spell it does not own into its contract, and the next…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Connections&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="notch swapping a live object lineages, and a hot swap taken end to end. an index is a version lineage with exactly one selected member. this lesson builds one, stages a second version onto it, shows that staging changes nothing about what resolves - which is why the swap is a two-step act - then takes the swap by the new version&#x27;s spell_id, melds it at the index&#x27;s address, and notches back. everything runs on public calls. the three verbs book.bind(...) v1 active on a fresh index conduit.bind_inactive(...) v2 parked on the same index; returns v2&#x27;s spell_id conduit.notch_spell( v2 becomes the active member spell_index=index, spell_id=v2_id) every version is bound the way the first one was. an index keeps its first version&#x27;s binding for life: the kind of spellframe (none, a string category or a protocol) and the address that gives - the spellframe&#x27;s name, or a bare class&#x27;s own name, and the binding name. `bind_inactive` refuses a version bound any other way before anything is registered, so a retry with the right arguments is admitted. that is why a notch never moves the address, and whoever melds by the address follows the notch. two classes cannot share a bare address, so v1 and v2 are both bound under one string category, &quot;pricing&quot; (2026-10-25; until then a version could be staged at any address and a notch moved the address with it). name the version by its spell_id. a spell_id names one version, and the public spell_id-&gt;object lookups (`get_spell_by_spell_id`, `find_spell_by_spell_id`) answer exactly that version, active or parked (owner ruling 2026-10-17; until 0.2.8253 they answered a parked spell_id with the active member). `notch_spell` takes the spell_id too and resolves the exact version inside the call. the spellbook is still not the surface you notch from - the conduit&#x27;s verb does the resolving (owner ruling 2026-10-16; until then the verb took only the parked object, no public door handed one out, and this lesson stopped at staging). what staging actually buys you `bind_inactive` puts a real, bound, owned spell into the lineage and leaves the selection alone. the candidate is inert and unmeldable until something promotes it. that separation is what lets a swap be prepared long before it is taken - the expensive, failure-prone half (compiling and registering a new version) happens while the old version is still serving. and what a notch does when it happens 0. checks the version: it must belong to the conduit&#x27;s spellbook and to the index you passed, or the call raises valueerror before anything moves. 1. moves the address&#x27;s frame claim from the outgoing version to the incoming one in one compare-and-set. when another spell holds the address it raises runtimeerror naming the holder, and nothing moves. 2. parks the outgoing active spell off the four active owned maps, then tears down its creation context so the door epoch bumps and the warm fast-door cannot serve the stale spell. 3. promotes the parked candidate into the active maps and repoints the index pointer, old spell_id -&gt; new spell_id. 4. re-registers the index gated + dirty, so revalidation recompiles lazily on the next resolve rather than inside the window. all of it happens under one seal, and the sealed conduits&#x27; creation gates are quiesced for the duration, so no in-flight meld can straddle the repoint. you do not arrange any of that; the verb does, the same way `link` does in expert 16. the outgoing version is not destroyed. it stays a member of the lineage, parked, with the object it built, which is why a rollback is structurally the same act as the swap - a notch back by its spell_id - rather than a restore. mind the layer when you read the source. `_apply_notch` says contracted borrowers are &quot;not yet fanned out here (owner-side only)&quot;. that here is load-bearing: the seam is the local switch, and `conduit.notch_spell` one layer up does walk the links. a statement read out of its scope becomes a false one. conduit.bind_inactive, conduit.notch_spell(spell_id=...), conduit.meld(spellframe=...), spellindex.selected_spell_id / spells_in_index, conduit.get_spell_by_spell_id registration resolution connections persistence &amp; restore research &amp; change concurrency"><span class="example-level">🔵 Expert · 17</span><h3><a href="17-notch-swapping-a-live-object.html">Notch swapping a live object</a></h3><p>LINEAGES, AND A HOT SWAP TAKEN END TO END. An index is a version LINEAGE with exactly one SELECTED member. This lesson builds one, stages a second version onto it, shows that staging…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Connections</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="the package reads itself to you you do not read a system document, you address it. four documents hang off the package root and answer at import - before aether boots, before a spellbook exists, before anything is conjured. md.__architecture__ prose, addressable by section md.__components__ prose, addressable by section md.__graph_network__ the same, plus a graph api md.__graph_details__ the same `systemgraphview` subclasses `systemdocumentview`, so the graph documents answer every prose question too and then add nodes and edges on top. ask what the address space is before you address it view.addressing -&gt; &quot;section&quot; | &quot;source_path&quot; keys are heading paths in one document and repository-relative file paths in another. a caller that assumes one shape silently misses in the other, so the view publishes which it is rather than making you infer it from a sample. the cheap survey, then the expensive read keys() every section key, in document order groups(depth) the index collapsed to one row per prefix index() every section(key, start_line, end_line, line_count) find(needle) sections whose key matches search(needle) sections whose body mentions it, ranked by hit count, with a preview note that `find` and `search` answer different questions - one addresses, one investigates - and neither one costs you the document. only then: get(key) the section&#x27;s text reader(key, ...) a private cursor over one section `reader()` taking a key is the whole design. the paging cursor is scoped to a section, so an agent that has narrowed correctly never pages the document at all. citations, not paraphrases cite(key) -&gt; &quot;src_graph.md:3518-3596&quot; cite(key, line=3520) -&gt; &quot;src_graph.md:3520&quot; an agent can hand back an address a human can open and check. that is a different kind of answer from a summary: it is falsifiable. refused is not missing available -&gt; did this document ship with content reason -&gt; why not, when it did not verify() -&gt; re-check the shipped text against the digest its index claimed a document that fails verification still exists and still answers `available` and `reason`. omitting it would make a stale index look identical to a document that never existed - and the second one invites an agent to invent. `verify()` is always false for an unavailable document, because there is nothing to check. md.__architecture__ / __components__ / __graph_network__ / __graph_details__ - addressing, keys, groups, index, find, search, section, get, cite, reader, verify, and the graph surface agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🔵 Expert · 18</span><h3><a href="18-the-package-reads-itself-to-you.html">The package reads itself to you</a></h3><p>YOU DO NOT READ A SYSTEM DOCUMENT, YOU ADDRESS IT. Four documents hang off the package root and answer AT IMPORT - before Aether boots, before a Spellbook exists, before anything is…</p><div><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;]" data-search="the codebase as a walkable graph the graph documents. expert 18 addressed prose by section. the two graph documents carry the same prose surface and a real graph: nodes, edges, traversal, and blast radius - answered at import, with nothing conjured. md.__graph_network__ the graph md.__graph_details__ the prose about what the graph names the one that changes how you work graph.node_at(source_path, line) you have a traceback. you have `file.py:412`. that call turns a line number into the node that encloses it, and from there `impact()` tells you what else moves if you change it. stack trace to blast radius without leaving the process. every edge explains itself edge(source, relation, target, cardinality, phase, origin, why) two fields there are unusual and both are the point: `why` - the justification for the edge, carried with it `origin` - `authored` or `derived`: did a human assert this, or did a tool infer it? `origin` is a trust filter you can pass to `walk()` and `impact()`. walk only `authored` when you need what someone meant; walk only `derived` when you need what the machine can prove. a graph that cannot tell you which is which forces you to trust all of it equally, which in practice means trusting none of it. and guesses do not ship. `edge_count` excludes extractor candidates - the leads over-generate roughly eightfold and never reach the adjacency table. what you walk is evidence. `walk()` yields, and that is a context budget decision it is a generator &quot;so an agent can stop at the first useful hop instead of materialising a subgraph it will discard&quot; - expert 18&#x27;s law again, one grain up. breadth-first, so shallow relationships arrive first and stopping early stops at the right things. two guarantees that make a walk safe - cycles are handled. `borrows` and `used_by` run both ways, so the graph has cycles and every node is expanded at most once. an unguarded walk would not terminate. - an edge to an unknown node is still yielded, then not expanded. &quot;the relationship is real even where the target is not described here.&quot; a graph that hid those edges would quietly understate what touches what. impact is measured in files impact(node_id) -&gt; impact(source, hops, nodes, edges) ranked by proximity, nearest first. not &quot;here are 400 symbols&quot; - here are the files, in the order you should look at them, in the unit you actually open and edit. and the two documents join details_key(node_id) -&gt; the section key in the details document describe(node_id) -&gt; that section&#x27;s text a node in the network document addresses prose in the other one. that is why they ship as a pair. md.__graph_network__ / __graph_details__ - node_count, edge_count, relations, node_ids, node, find_nodes, nodes_in, node_at, edges_from, edges_to, neighbors, walk, impact, details_key, describe inspection agent rooms &amp; codegen research &amp; change"><span class="example-level">🔵 Expert · 19</span><h3><a href="19-the-codebase-as-a-walkable-graph.html">The codebase as a walkable graph</a></h3><p>THE GRAPH DOCUMENTS. Expert 18 addressed prose by section. The two graph documents carry the same prose surface AND a real graph: nodes, edges, traversal, and blast radius - answered at…</p><div><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Lifetimes &amp; cleanup&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="the workstation an agents workbench the workbench. a codegen room is not just a place to run code - it has a workstation, a room-local canvas where an agent keeps named handles on things between commands. advanced 12 introduced it as a store. this is what it is for. the loop that makes it a workbench workstation.bind_object(&quot;service&quot;, obj) workstation.set_target(&quot;service&quot;) commands.execute_target_method(&quot;compute&quot;, bind_as_name=&quot;result&quot;) workstation.set_target(&quot;result&quot;) a command&#x27;s return value becomes the next named binding. so an agent works in steps, each one addressable by a name it chose, without carrying objects around in its own head or re-deriving them from the runtime on every call. three stores, one namespace each bind_object / bind_attribute / bind_method binding one name into two stores is allowed - they do not collide on write. but a bare `get(name)` must resolve uniquely, and when two stores answer it refuses as ambiguous rather than picking one. so the stores are separate for writing and deliberately unmerged for reading; `get(name, store=...)` is how you mean one of them. `describe_bindings()` reports five keys, not four: the fifth is `target_store`, which names which store the active target came from, so a target round-trips through `get(name, store=...)`. strong or weak, and the choice is enforced `weak_ref=true` on something that cannot be weak-referenced raises rather than silently storing it strongly. a silent degrade would pin an object the caller believed was collectable - the bug you find three weeks later as a memory graph that never shrinks. and a collected weak binding tells the room. weak-binding collection publishes an event into the room&#x27;s own event system, so &quot;the thing i was holding went away&quot; is something an agent can be told rather than discover by dereferencing a hole. two ways to stop pointing at something, and they differ clear_target() deselect; the binding stays, the object lives cleanup_target() call cleanup on the target, then deselect one is putting the tool down. the other is dismantling it. the security line, stated plainly `commandsystem` gates runtime access before a bind and leaves already-bound workstation objects outside post-bind acl policing. getting a handle is the checkpoint; using the handle you were granted is not re-litigated on every call. know which side of that line you are on when you bind something. and the workstation never fabricates. it stores room-local bindings only - it will not construct, resolve, or meld anything for you. resolution is the command system&#x27;s job; holding is the workstation&#x27;s. `cleanup()` clears the stores and deliberately does not clean the objects inside them, because it did not make them. rift.space.workstation - bind_object / bind_attribute / bind_method / get / release / describe_bindings / set_target / get_target / clear_target, and command_system.execute_target_method(bind_as_name=...) registration resolution lifetimes &amp; cleanup inspection agent rooms &amp; codegen persistence &amp; restore research &amp; change concurrency"><span class="example-level">🔵 Expert · 20</span><h3><a href="20-the-workstation-an-agents-workbench.html">The workstation an agents workbench</a></h3><p>THE WORKBENCH. A codegen room is not just a place to run code - it has a WORKSTATION, a room-local canvas where an agent keeps named handles on things between commands. Advanced 12…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Lifetimes &amp; cleanup</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Lifetimes &amp; cleanup&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Concurrency&quot;]" data-search="many agents writing code at once real codegen, and several agents doing it at once. expert 12 drove the loop once, on one thread. this is the shape melder is actually built for: four agents, four rooms, one shared world, concurrent. how data comes back out of generated code the executor runs the source in a controlled namespace and lifts one name out of it: code = &quot;total = 0\nfor n in range(1, 101):\n total += n\n&quot; &quot;result = total\n&quot; payload = commands.execute_codegen(code, frame_name=...) payload[&quot;result&quot;] # 5050 `result` is the convention, not a guess - `codegenexecutionresult` is built with `result=` taken from the namespace after the code runs. anything else the code computed stays in the sandbox and dies with it. one name out means the boundary is a value, not a scope an agent can leak through. the payload is a verdict, not a return value `accepted` and `frame_name` are always there; `reason`, `runtime_error`, `validation_issues` and `result` fill in according to what happened. so the same shape describes a refusal, a crash, and a success - an agent branches on `accepted` instead of catching, exactly as expert 12 established. four agents, four rooms, one world each agent opens its own rift, so it gets its own room, its own workstation, and its own memory. what they share is the target frame - the world their code lands in. that is the isolation melder actually offers: private benches, shared world. what is and is not serialized nothing in this lesson opens a transaction, because generated code that computes a value mutates no structure. melder serializes structural change; arithmetic in a sandbox is not structural, so four agents run genuinely in parallel and none of them waits. the moment one of them binds or links, the plane underneath arbitrates - and still none of this vocabulary appears in the agent&#x27;s code. a room&#x27;s memory is its own subscribe on one room and you see that room&#x27;s commands. the other three are running the same verbs at the same time and none of them appears in your log. per-agent audit falls out of per-agent rooms rather than being a feature anyone had to add. several codegen rifts driven from threads, validate_codegen / execute_codegen payloads, the `result` namespace lift, and per-room memory registration resolution lifetimes &amp; cleanup connections inspection agent rooms &amp; codegen concurrency"><span class="example-level">🔵 Expert · 21</span><h3><a href="21-many-agents-writing-code-at-once.html">Many agents writing code at once</a></h3><p>REAL CODEGEN, AND SEVERAL AGENTS DOING IT AT ONCE. Expert 12 drove the loop once, on one thread. This is the shape melder is actually built for: four agents, four rooms, one shared world,…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Lifetimes &amp; cleanup</span><span class="example-topic">Connections</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="asking what code would do before running it foresight. an agent about to replace a version can ask what the replacement would do - what it defines, what it imports, how it differs from what is there, what it would break, and whether the room would even permit it - and get all of that without running, binding, or recording anything. commands.research_preview( candidate_source, against_spell_id=existing_spell_id, frame_name=frame, ) one call, five answers defines / import_roots what the candidate declares and pulls diff would-be source + structural diff against the version it would replace impact the blast radius of that replacement, joined with research residency candidate_sha256 the identity it would have validation the room&#x27;s normal codegen verdict, but only when frame_name is supplied that last one matters: `validate_codegen` answers &quot;am i permitted&quot;, `research_preview` answers &quot;what would happen&quot;, and passing a frame folds the first into the second so an agent asks once. order of setup is load-bearing, in two separate ways 1. a bind only auto-records into a live research root. the seam returns quietly when research is absent, cleaned or inactive, because &quot;research bookkeeping never gates a bind&quot;. so a world built before you activate research is a world research never saw. activate first, then build. 2. and a recorded world must be born configured. with custody active, a dynamic conjure refuses outright if any bind ran before the spellbookconfiguration was finalized: md.spellbookconfiguration(frame).with_defaults().finalize() md.spellbook(aetheric_frame=frame, configuration=...) book.bind(...) # now the binds are config-coherent book.conjure(dynamic=true) the reason is stated in the refusal itself: the profile record, the checkpoints and the default bootstrap would durably persist binds that ran against unsettled configuration. a runtime can tolerate that; a record cannot, because the record is what a future boot rebuilds from. automatic-mode worlds and worlds with no active crystallizer are exempt, so nothing that is not being recorded pays for this. note which lessons this caught: every lesson in this tier that activates custody and conjures dynamic, and none of the others. the rule is narrow and it is exactly as narrow as the risk. and foresight needs custody. the impact half reaches through the crystallizer for the physical picture (expert 14&#x27;s record-vs- foresight split), so it refuses loudly when custody is not recording rather than handing back an empty radius. the proof that preview is read-only is in this file the lesson reads the research heads before and after the preview and asserts they are identical. &quot;nothing executes, binds, or records&quot; is a claim melder makes about itself; here it is checked. a broken candidate answers, it does not explode hand it source that does not parse and `parse_error` comes back populated with the rest of the payload still shaped the same way. an agent generating code gets malformed output sometimes; a foresight tool that raised on it would be useless exactly when it is needed. research_preview (defines / import_roots / diff / impact / candidate_sha256 / parse_error), research_impact, research_heads, and the crystallizer + mutationresearch activation order registration resolution configuration agent rooms &amp; codegen persistence &amp; restore research &amp; change concurrency"><span class="example-level">🔵 Expert · 22</span><h3><a href="22-asking-what-code-would-do-before-running-it.html">Asking what code would do before running it</a></h3><p>FORESIGHT. An agent about to replace a version can ask what the replacement WOULD do - what it defines, what it imports, how it differs from what is there, what it would break, and whether…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Lifetimes &amp; cleanup&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="branching the record and joining back branching, and why a join can refuse. research lanes are melder&#x27;s branches: parallel lines of versions over one world, anchored to each other, finished by joining. it looks like git until three places where it deliberately is not. a branch starts empty research_create_lane(&quot;try-a&quot;, attach_to=&quot;default&quot;, attach_at_spell_id=v1) anchoring records ancestry only. no node is copied, no node is moved, and the anchor lane is untouched - the new lane begins with zero versions and a memory of where it came from. that is the opposite of a git branch, which starts at a commit and carries the whole history with it. anchoring is all or nothing `attach_to` and `attach_at_spell_id` must be supplied together; exactly one of them raises before the lock is even taken. there is no &quot;anchor to whatever the tip is&quot; shorthand, because the anchor is the one fact the join later reasons about and a shorthand would let you record a different anchor than you meant. the default lane type is `experiment`, not `development` omit `lane_type` and you get `experiment` - deliberately not the default lane&#x27;s `development`. a freshly cut lane is an experiment until someone says otherwise, so the safe classification is the one you get by not thinking about it. and a join is divergence-aware, which is the whole lesson research_join(&quot;try-a&quot;, into=&quot;default&quot;) the clean path requires two things at once: the source is anchored onto the receiver, and the receiver&#x27;s tip is still at that anchor. anything else - the receiver moved on, a foreign anchor, no anchor at all - is a divergent join and refuses unless you pass `force=true`. the refusal names both tips, so you are told exactly what drifted apart rather than being handed a conflict to hunt. `force=true` is not a merge. it is an explicit supersede, and melder is blunt about the difference: &quot;reconciliation-by-content is not a join concern: compose in the codegen workshop, register the multi-parent result, then join.&quot; merging content is work you do with code, in a room, and the record only ever books the outcome. a version-control system that merges for you is guessing, and this one refuses to guess about your source. collapse chooses how much line comes with it collapse=false (default) fold the source&#x27;s full line in collapse=true move only the tip, leaving the rest readable in the joined source lane residence transfers with whatever moves, and the source is marked joined - it accepts no further work afterwards. a new version is bound the way the first one was. the receiver is moved by staging rulev2 on rulev1&#x27;s index, so both are bound under one string category and binding name, (&#x27;rule&#x27;, &#x27;branch&#x27;): an index keeps its first version&#x27;s binding, and bind_inactive refuses a version bound any other way (2026-10-25). research_create_lane (anchored, half-anchored and refused), research_heads, research_join with and without force, conduit.bind_inactive to move the receiver, and the lane payload create_lane returns (a lane describe() snapshot: lane_type, anchor, nodes) registration resolution lifetimes &amp; cleanup connections inspection agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🔵 Expert · 23</span><h3><a href="23-branching-the-record-and-joining-back.html">Branching the record and joining back</a></h3><p>BRANCHING, AND WHY A JOIN CAN REFUSE. Research lanes are melder&#x27;s branches: parallel lines of versions over one world, anchored to each other, finished by joining. It looks like git until…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Lifetimes &amp; cleanup</span><span class="example-topic">Connections</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Inspection&quot;, &quot;Persistence &amp; restore&quot;, &quot;Concurrency&quot;]" data-search="loading a whole world back seal a world, then unfold it again. expert 01 taught the pod-boot order; expert 09 taught what crosses the wire. this is the round trip itself - checkpoint a live world, put it in the cache, and unfold it back into the runtime. the five verbs, in order create_checkpoint(profile, description) -&gt; a ulid id describe_checkpoint(id) -&gt; what got captured flush_checkpoint(id) -&gt; seal it into the cache reload_cached_checkpoint(id) -&gt; cache back into ledger load_checkpoint(id) -&gt; unfold into the runtime only the last one touches the live world. the first four move a record around; `load_checkpoint` is the boot verb. the lesson retires its original root before replay so the saved root name and binding identities are available. the recorder itself stays alive. a restore is not a resurrection, and the report says so `load_checkpoint` hands back a restorereport carrying: status did it complete built counts how many of each kind came back shortfall entries what could not be rebuilt identity translation map old id -&gt; new id that last field is the one to understand. rebuilt objects get new identities - the world that comes back is equivalent, not identical - and the map is how you follow one thing across a boot. anything holding a raw pre-restore id and expecting it to still resolve is holding a stale address, and the map is the only honest way to translate it. shortfalls are reported, not hidden a spell whose class can no longer be imported, a module that moved, a binding whose target is gone - each becomes a shortfall entry rather than a silent omission. expert 18&#x27;s law at the boot grain: a restore that quietly dropped what it could not rebuild would look identical to a world that never had those things, and the second invites everyone downstream to invent. checkpoints accumulate; they never overwrite every `create_checkpoint` mints a new ulid and `list_checkpoint_ids()` returns them in exact ledger creation order. there is no &quot;the checkpoint&quot; - there is a history of them, and an id is the whole handle. and the operator&#x27;s one-call version md.crystallizerbootstrap() .with_crystallizer_configuration(...) .with_profile(...) .with_pull_remote(false) .bootstrap() that is expert 01&#x27;s flow: the same steps in a fixed sequence, for the case where you are starting a process rather than inspecting a round trip. note `with_preflight_gate` is an accepted no-op - the knob still exists and does nothing, and its own docstring says so rather than pretending. md.crystallizer create_checkpoint / describe_checkpoint / flush_checkpoint / list_cached_checkpoint_ids / list_checkpoint_ids / reload_cached_checkpoint / load_checkpoint, and md.crystallizerbootstrap registration resolution configuration inspection persistence &amp; restore concurrency"><span class="example-level">🔵 Expert · 24</span><h3><a href="24-loading-a-whole-world-back.html">Loading a whole world back</a></h3><p>SEAL A WORLD, THEN UNFOLD IT AGAIN. Expert 01 taught the pod-boot ORDER; expert 09 taught what crosses the wire. This is the round trip itself - checkpoint a live world, put it in the…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Inspection</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;]" data-search="many research sets one world research sets, plural. everything so far used the default set and never said there was a choice. a researchset is a whole independent body of history over the same runtime - its own lanes, its own residency, its own journal, its own campaigns. research.create_research_set(&quot;refactor-2026&quot;) research.list_research_set_names() research.research_set(&quot;refactor-2026&quot;) why more than one lanes branch a line of versions. a set is the thing lanes live in - so two sets are two entirely separate investigations that happen to be looking at the same world. expert 23&#x27;s join can never cross them, residency is per set, and a lane name in one set says nothing about a lane name in the other. two agents auditing the same runtime for different reasons do not have to agree on a lane vocabulary, or even know about each other. every research verb takes `set_name`, and it defaults root-level reads and writes carry `set_name=&quot;default&quot;`. that is why the first twenty-odd lessons never mentioned sets: the default was doing the work silently. the moment you have two, the argument stops being decoration. an unknown set name raises, and the error lists the known ones this is a small thing that matters enormously to an agent. a typo does not return an empty set that looks like &quot;no history here&quot; - it refuses and tells you what does exist, so the next call is correct instead of being another guess. compare with a silent empty: an agent would conclude the world had no record and act on it. and omitting the name resolves the default, not all sets. `research_set()` is &quot;the default one&quot;, never &quot;every one&quot; - so the cheap call is scoped rather than sweeping, and nothing accidentally reports across investigations that were meant to stay apart. the world is shared; the record is not the spells, the frames, the conduits - one runtime, seen by both. what differs is what each set has declared about it. a version can be resident in one set and unknown to another, and neither is wrong: a research set records what an investigation chose to look at, not everything that exists. mutationresearch.create_research_set / list_research_set_names / research_set, per-set lanes and residency, and the set_name argument on the root research verbs resolution agent rooms &amp; codegen research &amp; change"><span class="example-level">🔵 Expert · 25</span><h3><a href="25-many-research-sets-one-world.html">Many research sets one world</a></h3><p>RESEARCH SETS, PLURAL. Everything so far used the default set and never said there was a choice. A ResearchSet is a whole INDEPENDENT BODY OF HISTORY over the same runtime - its own lanes,…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;]" data-search="codegen create modify iterate the loop turned more than once - and the two books it writes. expert 12 drove the codegen verbs once. this iterates them, and in doing so hits the distinction that catches everyone: a codegen room and a research record keep different books, and only one is about your code. the turn - four verbs, only two of which change anything: research_preview(code, frame_name=) what would this do validate_codegen(code, frame_name=) am i permitted execute_codegen(code, frame_name=) do it materialize_codegen(code, module_name=, frame_name=) keep it running is not keeping. `materialize` takes a module_name because durability needs an address, and that is a separate decision from having run the code. `research_preview` is codegen-rooms-only, and that is the tell for why room types differ at all: it takes code, so it only exists where writing code is already the room&#x27;s business. a codegen room owns the full 34-command research family; a capability room owns twenty-one reads; a static room none. the two books the room&#x27;s what code was written. one record per successful top-level public command - every command, not just codegen ones - with a call-depth counter suppressing the tree underneath each call. the research what versions exist. written by `bind` (active), `bind_inactive` (staged) and a notch (promotion), and by nothing else. so `execute_codegen` writing a module does not mint a version. a bind does. cutting a lane and running three codegen turns leaves that lane empty, and this lesson asserts it. and single residence is why you cannot just file it elsewhere. one spell_id - the sha256 of a version&#x27;s code - lives in exactly one lane, network wide, permanently - there is no release verb. `bind_inactive` already declared the staged version onto `default`, so `register_spell(..., lane=...)` for that id raises the rediscovery signal naming the holding lane. that raise is a signal, not a failure: identical code always mints the same sha, and this is the system saying &quot;you built this before, here&quot;. the way to file it under a name is a different set - a set is its own residence partition, so a version resident in one is simply unknown to another. a staged version is bound the way the index&#x27;s first one was. rate is bound under the string category &#x27;rate&#x27; with binding name &#x27;iterate-rate&#x27; - the address a bare bind of rate has, so a meld of &#x27;rate&#x27; still finds it - and ratev2 is staged the same way. bound bare, ratev2 would be addressed by its own name, and bind_inactive refuses a version bound any other way (2026-10-25). codegencommandsystem.research_preview / validate_codegen / execute_codegen / materialize_codegen / research_create_lane / research_walk, mutationresearch.research_set / create_research_set, researchset.register_spell / create_lane / walk, conduit.bind_inactive registration resolution agent rooms &amp; codegen research &amp; change"><span class="example-level">🔵 Expert · 26</span><h3><a href="26-codegen-create-modify-iterate.html">Codegen create modify iterate</a></h3><p>THE LOOP TURNED MORE THAN ONCE - AND THE TWO BOOKS IT WRITES. Expert 12 drove the codegen verbs once. This iterates them, and in doing so hits the distinction that catches everyone: a…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Lifetimes &amp; cleanup&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;]" data-search="a world that outlives its own runtime tear the runtime down on purpose, then come back. expert 24 walked the five checkpoint verbs while the world stayed up. this is the harder half: seal a world, destroy the aether singleton, collect the garbage, and unfold the record into a runtime that has never seen it. the one fact the whole lesson turns on ledger -&gt; in-process, dies with the singleton cache -&gt; bytes at rest, survives it `create_checkpoint()` mints into the ledger. that is memory. tear the root down without flushing and the checkpoint goes with it - nothing to come back to and no error to tell you so, because nothing went wrong. `flush_checkpoint(id)` is what makes a record outlive the process. the teardown is public, and identity-checked aether.cleanup() singleton bookkeeping is cleared in a `finally` - `_instance` and `_initialized` - so it resets even when a child teardown raises. before that `finally` existed, one failing child left a cleaned husk installed as the process singleton for the rest of the run. `cleanup()` is the reset; the private `_reset_singleton_for_tests` beside it is for test isolation, and nothing below reaches for it. `gc.collect()` here is real work, not ceremony: melder cleans deterministically rather than leaving owned objects to the collector, so a collect is how the old world is proven gone. and the last rung demands a complete bundle unfolding into a virgin runtime is the strictest act here and the one that can refuse. `load_checkpoint` is mediated: the folded chain pre-flights before any replay, and a `blockers` verdict refuses at the one seam owning authoritative folded truth. a refusal ends &quot;nothing was built&quot; - all-or-nothing declining to start rather than half-building a world and unwinding it. the chain comes from the ledger, which is the part worth knowing. `plan_checkpoint_load` detaches the target&#x27;s same-profile chain in creation order, not the single id you named. after a teardown the fresh ledger is empty and `reload_cached_checkpoint` restores only the id you ask for - so a world sealed across several checkpoints and partially reloaded folds an incomplete chain and refuses exactly as a corrupt one would. seal more than once and you want `flush_checkpoint()` with no argument, then every id back. md.crystallizer create_checkpoint / flush_checkpoint / list_checkpoint_ids / list_cached_checkpoint_ids / reload_cached_checkpoint / load_checkpoint, md.aether cleanup, and the codegen room&#x27;s validate_codegen / execute_codegen / materialize_codegen across the boundary resolution lifetimes &amp; cleanup agent rooms &amp; codegen persistence &amp; restore"><span class="example-level">🔵 Expert · 27</span><h3><a href="27-a-world-that-outlives-its-own-runtime.html">A world that outlives its own runtime</a></h3><p>TEAR THE RUNTIME DOWN ON PURPOSE, THEN COME BACK. Expert 24 walked the five checkpoint verbs while the world stayed up. This is the harder half: seal a world, DESTROY the Aether singleton,…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Lifetimes &amp; cleanup</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Inspection&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="the record crosses as a json string no file, no database, no driver - a python string. merge two research lanes, turn the whole record into text, throw the live set away, and rebuild it from that text with its identity intact. the two verbs that make a record portable research_set.describe() -&gt; dict[str, object] md.researchset.from_payload(d) -&gt; researchset `describe_composition()` guarantees &quot;plain-value throughout. every nested value is json-safe&quot;, which is why this script calls `json.dumps(payload)` with no `default=` handler. the strict call is the guard: the day something non-plain lands in that payload it raises typeerror and names the offender. a `default=str` would turn a broken guarantee into a silently lossy round trip - a datetime would go out as a string, come back as a string, and nothing would notice. what survives, and why it matters `from_payload` restores the recorded identity - the rebuilt set keeps its `set_id` and `created_at` rather than minting new ones. so this is not &quot;a set that looks like the old one&quot;; it is the same set, hydrated. contrast expert 24/27, where a restored world is deliberately equivalent-not-identical and hands you a translation map. runtime objects are rebuilt; the record is restored. it also carries `network_versioner`, so the undo ring survives and `restore_network` still reaches pre-death shapes on the rebuilt set. rebuild is silent by design: `on_mutation` is suppressed during hydration and installed at the end, so rehydrating does not re-fire persistence for every recorded node. and the join order is load-bearing. the clean join happens while the receiver still sits at the anchor; move the receiver first and even the &quot;clean&quot; branch is divergent. the lanes stay empty on purpose - `bind_inactive` declares its version into `default` automatically, and single residence means that id then lives in exactly one lane, so registering it onto a branch would raise the rediscovery signal instead (expert 26 shows that refusal). and the staged version is bound the way the index&#x27;s first one was: policy under the string category &#x27;policy&#x27; - the address a bare bind of policy has - with binding name &#x27;wire-policy&#x27;, and policyv2 the same; bind_inactive refuses a version bound any other way (2026-10-25). md.researchset.from_payload, researchset.describe / lane_names / walk / set_id / network_snapshot_shas, research_create_lane / research_join / research_heads, conduit.bind_inactive, and the mesh quartet (with_store_handler / with_fetch_handler) registration inspection persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 28</span><h3><a href="28-the-record-crosses-as-a-json-string.html">The record crosses as a json string</a></h3><p>NO FILE, NO DATABASE, NO DRIVER - A PYTHON STRING. Merge two research lanes, turn the whole record into TEXT, throw the live set away, and rebuild it from that text with its identity…</p><div><span class="example-topic">Registration</span><span class="example-topic">Inspection</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="reading your own recorded code the crystal well - reading the code your world recorded, at four grains, and the one comparison law that makes any of it trustworthy. expert 04 said diffs are derived, never stored. this is what they are derived from. the four grains, widest to narrowest research_source(spell_id) the whole module world research_module(spell_id, module_name) one module, full dossier research_parts(spell_id) every part, with code research_part(spell_id, part_name) one named class/function they are not four ways to do one thing. `research_parts` is the inventory - it needs no names up front, which is exactly what you want before you know what is in there. `research_part` is the lookup for when you do. `research_module` is the one-call dossier: text, fingerprint, path, dependencies both ways, export surface and drift together, because separately fetching those is five calls and a join. the comparison law, and it is the point `research_part_diff(left, right, part)` compares recorded material only and never the live disk. that refusal is correctness, not caution: both sides of a version comparison would read the same present-day file, so a disk-backed diff would report &quot;no change&quot; between two genuinely different versions and be confidently wrong about both. the record is the only place where two versions exist at the same time. diff material drinks both carriers - synthetic first, user-retained filling the gaps - so it speaks the full module whether the code was generated or hand-written. impact stays module-grain on purpose. a part&#x27;s honest blast radius is its module&#x27;s radius, because nothing imports half a file. a part-grain number would be smaller and mean nothing. custody is required and the refusal is loud. these read from the recorded world, so an absent or inactive crystallizer raises rather than returning empty - a silent empty read is indistinguishable from &quot;this world has no code&quot;, which is never true. this lesson catches that refusal and says so rather than pretending every environment can serve it. validate_codegen / materialize_codegen, research_source / research_module / research_parts / research_part / research_part_diff / research_module_graph / research_source_drift / research_impact / research_residency / research_history / research_recent, conduit.bind_inactive registration inspection agent rooms &amp; codegen persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 29</span><h3><a href="29-reading-your-own-recorded-code.html">Reading your own recorded code</a></h3><p>THE CRYSTAL WELL - reading the code your world RECORDED, at four grains, and the one comparison law that makes any of it trustworthy. Expert 04 said diffs are derived, never stored. This is…</p><div><span class="example-topic">Registration</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Connections&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="composing a version in the workshop the half of a merge that join refuses to do, on code the room actually generated. expert 23 said it outright: &quot;reconciliation-by- content is not a join concern: compose in the codegen workshop, register the multi-parent result, then join.&quot; this is that workshop, and the material is real codegen output - not classes typed into this file. a record that merged content for you would be guessing about your source. so melder splits the act in two: you compose (here), and the record books the outcome (expert 23). nothing in between. the composition verb research_synthesize(base_spell_id, donor_spell_id, take_functions=, take_classes=, stage_ancestry=false) take named top-level functions/classes from the donor&#x27;s root module, splice them into the base&#x27;s, and hand back the composed source with a full foresight preview. nothing executes, binds or records - it is a candidate, not a version. synthesis is module-grain. the engine says so itself: it &quot;splices one version&#x27;s module world&quot;. each id resolves to its root module text, and `take_functions` / `take_classes` name top-level parts of that module. a method is not a top-level function. asking for one raises, and the refusal names what the donor actually carries - which is how you discover the grain if you guessed wrong. which is why this lesson generates its two modules. two classes typed into one example file resolve to the same module, so every selection is a part replaced by itself and &quot;added&quot; is unreachable - the splice degenerates into a no-op that proves nothing. real composition needs two module worlds, so the room writes them: validate_codegen -&gt; materialize_codegen -&gt; import -&gt; bind that is the documented loop - materialize&#x27;s own contract calls binding the class inside the new module the step that &quot;closes the codegen -&gt; synthmodule -&gt; bind -&gt; crystal loop&quot;. and generated code is the more reliable source, not the exotic one: &quot;synthetic module sources are always harvested; user module text rides the opt-in retention lane&quot;. the material a room wrote is the material it can always read back. and the diff default is kind-aware, not a single fallback. research_diff(left, right, strategy=none) with no strategy the room asks what you handed it. two spells get &quot;structural&quot; - the room&#x27;s reasoning layer - pinned for them. two compositions get nothing pinned at all: the room passes no strategy and the engine&#x27;s own &quot;members&quot; default answers. one verb, two vocabularies, selected by kind. (&quot;source&quot; is whole-module text, &quot;parts&quot; is per-class/function grain; both are always yours by asking.) a default is a kindness for silence, never an override. name a strategy and it travels down untouched - an unknown one surfaces the engine&#x27;s keyerror rather than being quietly answered by a different question than the one asked. the mint is a separate, one-shot stamp research_stage_ancestry([base, donor]) research_clear_staged_ancestry() staging says &quot;the next fresh world entry has these parents&quot;. it is consumed once and it is ambient, not attached to any particular call. a rediscovery does not consume it - identical content re-entering the world is not the synthesized candidate arriving. and the stamp survives until used or cleared. no scope ends it, which is why `clear_staged_ancestry` exists: abandon a composition and you must clear, or the next unrelated bind inherits parents it never had. validate_codegen / materialize_codegen / research_synthesize / research_stage_ancestry / research_clear_staged_ancestry / research_diff registration resolution connections agent rooms &amp; codegen persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 30</span><h3><a href="30-composing-a-version-in-the-workshop.html">Composing a version in the workshop</a></h3><p>THE HALF OF A MERGE THAT JOIN REFUSES TO DO, on code the room actually generated. Expert 23 said it outright: &quot;Reconciliation-by- content is not a join concern: compose in the codegen…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Connections</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="organising lanes after the fact lanes are organised after the fact, not planned in advance. expert 23 cut branches and joined them. this is the other three verbs - the ones for when you got the shape wrong the first time. research_attach(lane, onto=, at_spell_id=) re-anchor ancestry research_detach(lane) forget the anchor research_archive(lane) retire a dead end ancestry is organisation, not content. every one of these moves where a lane says it came from. none of them copies, moves or deletes a version. that separation is why re-organising is cheap and safe: the nodes never move, so a wrong anchor is a wrong label rather than lost work. attach is all-or-nothing, and it refuses before taking a lock: `onto` and `at_spell_id` must both be supplied. there is no &quot;anchor to whatever the tip is&quot; shorthand, because the anchor is the one fact a later join reasons about - a shorthand would let you record a different anchor than you meant. detach is not a delete. it removes the anchor, leaving a lane that remembers nothing about where it came from. a detached lane can still be joined, but the join is divergent by definition - no anchor means nothing for the receiver&#x27;s tip to agree with - so it needs the same explicit `force=true` supersede. archive retires a lane without losing it. residence is permanent: the versions stay resident in the archived container, rediscovery still points at it, and a network snapshot can restore a view that contained it. archiving hides a dead end from the active view; it does not unmake it. and the default lane never archives. it is the guaranteed world-entry record - `register_spell` without a lane records there, and `default_lane` resolves by well-known name - so a set that archived it could not serve its own default. the refusal is checked at the door rather than discovered later. the receiver moves by a new version, bound the way the first was. rule is bound under the string category &#x27;rule&#x27; - the address a bare bind of rule has - with binding name &#x27;organise-rule&#x27;, and rulev2 is staged the same way; bind_inactive refuses a version bound any other way (2026-10-25). research_create_lane / research_attach / research_detach / research_archive / research_join / research_heads, researchset.lane_names, conduit.bind_inactive registration resolution persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 31</span><h3><a href="31-organising-lanes-after-the-fact.html">Organising lanes after the fact</a></h3><p>LANES ARE ORGANISED AFTER THE FACT, NOT PLANNED IN ADVANCE. Expert 23 cut branches and joined them. This is the other three verbs - the ones for when you got the shape wrong the first time.…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="a subsystems blast radius ask a whole subsystem what it would break. expert 14 built compositions - a set of versions pinned as one unit. this asks the two questions you actually have about one: how far does it reach, and has the ground moved under it. research_group_impact(group_id) the union blast radius research_group_drift(group_id) recorded-vs-disk, narrowed impact is a union with closure math, not a sum. it merges every member&#x27;s radius and then splits the result internal vs outbound: how much of the blast lands back inside the composition, and how much escapes it. the closure fraction is the number that matters - a subsystem with high closure is one you can change on its own terms, and a low one is a subsystem in name only, whose edges are really everyone else&#x27;s problem. it also lifts to composition grain: the radius names the other compositions it touches (`affected_compositions`), so &quot;what else does this subsystem hit&quot; is answerable in subsystem vocabulary rather than as a flat list of spells. drift is the same report as `research_source_drift`, narrowed to the footprint - and the narrowing is the point. a whole-world drift report on a real repository is mostly other people&#x27;s churn. asked about one subsystem, the counts are recomputed over that subsystem&#x27;s modules only, so the answer is about your area rather than about the repository&#x27;s mood. compositions are informational, which is why these are cheap to ask. a composition pins members by reference; it carries no custody crystal of its own, gates nothing and never executes. both of these verbs are derived reads over the members&#x27; recorded material - there is no subsystem-shaped thing at runtime to disturb. and the footprint is honest about what it cannot see. a member whose custody is unknown is reported as unknown rather than silently contributing nothing - a shadow with a hole in it that claimed to be complete would be worse than no shadow. evolving one is add/remove, not replacement. `recompose` says it outright - &quot;unlisted members are retained&quot; - so dropping a member is a one-word ask rather than a re-declaration of the roster. the previous composition is untouched by it, because identity is content-addressed over the members: a different roster is simply a different composition, not an edited one. and it completes expert 30&#x27;s diff law. there you met `research_diff` on two spells, where the room pins `structural` for you. hand the same verb two compositions and it pins nothing - it stands back and lets the engine&#x27;s `members` default answer, because the useful question about two subsystems is which members changed, not how their text reads. one verb, two vocabularies, chosen by kind. validate_codegen / materialize_codegen, research_group_register / research_group_recompose / research_group_impact / research_group_drift / research_group_footprint / research_group_view / research_group_diff / research_diff agent rooms &amp; codegen persistence &amp; restore research &amp; change concurrency"><span class="example-level">🔵 Expert · 32</span><h3><a href="32-a-subsystems-blast-radius.html">A subsystems blast radius</a></h3><p>ASK A WHOLE SUBSYSTEM WHAT IT WOULD BREAK. Expert 14 built compositions - a set of versions pinned as one unit. This asks the two questions you actually have about one: how far does it…</p><div><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="what a synthetic module actually is what a synthetic module actually is, and why one crystal shape holds both it and a file on your disk. lessons 26, 27, 29, 30 and 32 all make synthetic modules. none of them says what one is. this does. a synthetic module is a real module with no file. it is a live `moduletype` subclass the crystallizer owns: it carries its own source text and hash, registers with a class-level import registry behind a meta-path finder, and answers plain `import name` like anything else. its source is the record - there is no file to go read, so there is nothing to go stale. four states, none inferred from another: registration, import-hook install, publication into `sys.modules`, and source execution. `materialize_codegen` is the convenience path that composes all four. and it publishes before it executes, deliberately - that is how importlib treats real modules, so a circular import sees a partially-initialised module instead of a missing one. custody is how the crystallizer decides what a module *is*. bind walks your object&#x27;s dependencies and classifies every module it meets through four authority classes, taking the first that matches: synthetic_module claims by object identity (isinstance), never path - because a path rule would misclassify it. reads no disk. makes no fingerprint claim; its rebuild payload already carries source_sha256. user_source claims by path under the configured user roots. the only fingerprint custodian - a bind-time sha256 over your source. this is the trust boundary, and it is the whole reason drift is detectable at all. site_package installed distributions. descends and reads, but claims nothing - you did not write it, so its changing is not your bug. unknown the fallback: pathless, unresolvable, binary. the only class that does not descend. recorded as an honest leaf so the manifest never implies a more complete picture than the source supports. so the answer to &quot;can this drift&quot; is decided by custody, not by chance. only user source is fingerprinted, so only user source can be caught changing under you. a synthetic module cannot drift - not because drift is unchecked but because its text is the record. and bind formats both into one crystal. there is no synthetic crystal and no file crystal. one flat module inventory, plus four kind-partitions that are subsets of it, plus `root_module_kind` naming which lane the root took. the kind is data in the crystal, not a different crystal - which is exactly why a world can mix generated and hand-written code and still checkpoint as one thing. a note on what this lesson points at. `syntheticmodule`, the custody strategies and `spellcrystal` are all agent_access: internal - &quot;read it to understand the runtime, do not drive it directly&quot;. they are named here because you cannot reason about your own world without knowing they exist. every line below drives the public surface only. validate_codegen / materialize_codegen / research_source / research_module / research_source_drift registration resolution configuration inspection agent rooms &amp; codegen persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 33</span><h3><a href="33-what-a-synthetic-module-actually-is.html">What a synthetic module actually is</a></h3><p>WHAT A SYNTHETIC MODULE ACTUALLY IS, and why one crystal shape holds both it and a file on your disk. Lessons 26, 27, 29, 30 and 32 all MAKE synthetic modules. None of them says what one…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="several worlds of record in one process keep two separate worlds of record in one process. every lesson so far has recorded into one nameless place. it has a name - &quot;default&quot; - and you can have others. a profile is where emissions land. twins accumulate into the active profile, and unqualified operations resolve to it. two profiles are two separate bodies of recorded content in one running process: a staging record and a production one, or one per tenant, or a throwaway you clear between experiments. but a profile is not a private ledger, and this is the thing to get right. `create_checkpoint` snapshots one profile&#x27;s window and advances that profile&#x27;s journal mark - the content is partitioned. `list_checkpoint_ids()` returns &quot;all checkpoint ids in exact ledger creation order&quot; for the process. switching profiles does not give you a filtered view and does not hide anyone else&#x27;s seals. same shelf, different boxes. assume otherwise and you will write an assertion that fails - this lesson&#x27;s author did exactly that. you create worlds by name and nothing else. the facade says so outright: &quot;users and agents create worlds by name only; persistenceprofile objects never escape the depths.&quot; you never hold the profile object, so there is nothing to pass around, alias, or accidentally keep alive - the name is the handle. that is worth contrasting with a surface that does not do this: the acl authoring chain hands you internal builders and is marked &quot;do not drive it directly&quot;. here the internal object is kept buried and you are given a name. same codebase, two answers, and the one you get tells you whether a surface is finished. switching moves a pointer. nothing else. `set_active_profile` &quot;moves the pointer only - no data is copied or migrated between profiles&quot;. nothing is merged, nothing is duplicated, and the profile you left keeps exactly what it had. if you expected a switch to bring your checkpoints along, this is the sentence that saves you. clear and delete are different verbs on purpose clear_profile empties it and keeps it - still listed, still activatable. the non-destructive reset. delete_profile removes it. the name stops appearing in list_profile_names(). and &quot;default&quot; is never deletable - it is the guaranteed landing place, the same shape of law as the default research lane that never archives (expert 31). every system needs one thing that cannot be removed, or its own fallbacks have nowhere to fall. all of it requires an activated crystallizer, and the refusal is the point: &quot;a configured-but-not-activated crystallizer raises rather than silently no-opping. recording is opt-in and this is where that shows up.&quot; a world that quietly recorded nothing would be worse than one that refused. crystallizer.active_profile_name / create_profile / set_active_profile / list_profile_names / describe_profile / clear_profile / delete_profile, with create_checkpoint proving the partition is real resolution configuration inspection agent rooms &amp; codegen persistence &amp; restore research &amp; change"><span class="example-level">🔵 Expert · 34</span><h3><a href="34-several-worlds-of-record-in-one-process.html">Several worlds of record in one process</a></h3><p>KEEP TWO SEPARATE WORLDS OF RECORD IN ONE PROCESS. Every lesson so far has recorded into one nameless place. It has a name - &quot;default&quot; - and you can have others. A PROFILE IS WHERE…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Resolution&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Concurrency&quot;]" data-search="the gate that waits for readers the admission gate, and why it is not a mutex. expert 16 rewired a running world and 17 staged a swap on a live object. neither said what makes those safe. this does. melder has three gates and they exist for one reason: riftgate admission to a rift&#x27;s guarded paths (here) creationgate the conduit&#x27;s meld path loadgate crystallizer loads &quot;all three exist because some operations must wait for readers rather than for other writers.&quot; read that twice. a mutex protects writers from each other. these make a writer wait until the last reader has left - which is the only way to swap something out from under live callers without tearing. tickets are what make draining truthful. a caller registers a ticket entering guarded work and unregisters on exit, and drain waits for the count to hit zero. a boolean &quot;busy&quot; flag would be a guess; &quot;a meld holds its ticket across the whole executor, so ticket-zero genuinely means no reader is inside&quot;. two control modes, and conflating them is the bug. blocking is reversible. disable parks new entrants, open() releases them. this is what an acl-driven projection refresh needs: block entrants, drain, refresh once, reopen. terminal close is one-way. it exists for shutdown, &quot;where reopening would be wrong&quot;. one is a door you hold shut; the other is a door you brick up. two entry modes, and this one is a policy choice about your agents. while a gate is disabled, `admit()` either waits or raises: &quot;wait&quot; the caller blocks until someone reopens &quot;raise&quot; the caller is told no, immediately an agent that blocks is patient; an agent that raises can go do something else. neither is right by default, which is why it is a setting rather than a behaviour. and now the honest part, which is the reason this lesson exists. no single verb proves a rift is empty, and melder says so in its own docstrings rather than letting you assume otherwise: disable_rift_gate stops new entry. it &quot;does not wait for threads already inside&quot;. close_and_wait_rift drains - but the timeout bounds the wait, so &quot;a return does not by itself prove the rift is empty&quot;. count_active_rift_threads tells you the truth, and is &quot;a diagnostic, not a synchronization primitive - do not spin on it&quot;. so quiescence is: close-and-wait (bounded), then check the count. most systems ship a `drain()` that implies a guarantee it cannot make. this one hands you three verbs and tells you what each one does not cover. one trap, stated plainly: disable/enable silently no-op for an unknown rift id. a typo does not raise - it succeeds and changes nothing. nexus.get_rift_gate / enable_rift_gate / disable_rift_gate / set_rift_gate_entry_mode / count_active_rift_threads / count_active_rift_threads_total / close_and_wait_rift, rift.id, and a command refused at the closed gate resolution agent rooms &amp; codegen persistence &amp; restore concurrency"><span class="example-level">🔵 Expert · 35</span><h3><a href="35-the-gate-that-waits-for-readers.html">The gate that waits for readers</a></h3><p>THE ADMISSION GATE, and why it is not a mutex. Expert 16 rewired a running world and 17 staged a swap on a live object. Neither said what makes those safe. This does. MELDER HAS THREE GATES…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Lifetimes &amp; cleanup&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;]" data-search="an agent builds a working system nothing in this file exists when the process starts. three classes are written as text at runtime, become real importable modules with no file on disk, get bound as spells, and come out as live objects that do actual work. then we make more of them. this is the demo. everything else in the tier explains a rule; this one just does the thing. the loop, one more time but with a payoff validate_codegen may this exist? materialize_codegen make it a real module import it resolves like anything else bind it becomes a spell with custody meld you get an object five steps from a string to something you can call a method on. and the objects are ordinary. that is the part worth sitting with. once melded, a generated class is not a special &quot;dynamic&quot; thing you handle with tongs. it is an object. it has state, you call methods on it, you pass it around, it participates in the same lifecycle as a class you typed by hand. the generated-ness stops mattering the moment it lands. multiple objects from one generated class. `existence=&quot;many&quot;` means every meld builds a new instance, so an agent can write one class and you can run a hundred independent copies of it - separate state, no shared surprises. `existence=&quot;unique&quot;` gives you the same object back every time. same generated source, two population models, and you choose per binding. why this survives a reboot, in one line: the module has no file, so its source is the record (expert 33). a world made of generated code is reproducible rather than merely re-runnable - which is what makes any of this more than a clever trick. validate_codegen / materialize_codegen, spellbook.bind with existence unique and many, conduit.meld, and the generated objects actually running registration resolution lifetimes &amp; cleanup agent rooms &amp; codegen persistence &amp; restore"><span class="example-level">🔵 Expert · 36</span><h3><a href="36-an-agent-builds-a-working-system.html">An agent builds a working system</a></h3><p>NOTHING IN THIS FILE EXISTS WHEN THE PROCESS STARTS. Three classes are written as text at runtime, become real importable modules with no file on disk, get bound as spells, and come out as…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Lifetimes &amp; cleanup</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Concurrency&quot;]" data-search="review agent bindings gate agent-supplied existing objects with ordered pre-bind checks, verify agent metadata and annotate the new spell during activation, then update and audit the published spell in post-bind. demonstrate rejection phases and why a post-bind failure does not undo registration. md.spellbook / find_spell_by_spell_id / describe_spells_in_spellbook, md.conduit.add_bind_hooks / clear_bind_hooks / bind / meld, md.spell.metadata / tags, md.hookexecutionerror registration resolution inspection agent rooms &amp; codegen concurrency"><span class="example-level">🔵 Expert · 37</span><h3><a href="37-review-agent-bindings.html">Review agent bindings</a></h3><p>Gate agent-supplied existing objects with ordered pre-bind checks, verify agent metadata and annotate the new Spell during activation, then update and audit the published Spell in post-…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Concurrency</span></div></li>
<li class="example-item" data-level="expert" data-topics="[&quot;Registration&quot;, &quot;Lifetimes &amp; cleanup&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;]" data-search="named scopes in nexus and restore observe named lesser scopes through nexus, then restore their recorded structure. new conduit ids need the normal explicit rift projection refresh. a known pooled id keeps its compiled membership while named reuse replaces its payload. crystallizer records dynamic scope structure and required unnamed ancestry; it does not save application instances or their mutable contents. md.crystallizer.activate / create_checkpoint / load_checkpoint, md.spellbook.configure_aether_frame / bind / conjure, md.nexus.activate / create_rift, md.rift.create_frame_link / refresh_runtime_projections, capability create_lesser_conduit / get_conduit_by_name, md.conduit.get_conduit_cloud / cleanup. registration lifetimes &amp; cleanup configuration connections agent rooms &amp; codegen persistence &amp; restore"><span class="example-level">🔵 Expert · 38</span><h3><a href="38-named-scopes-in-nexus-and-restore.html">Named scopes in nexus and restore</a></h3><p>Observe named lesser scopes through Nexus, then restore their recorded structure. New conduit IDs need the normal explicit Rift projection refresh. A known pooled ID keeps its compiled…</p><div><span class="example-topic">Registration</span><span class="example-topic">Lifetimes &amp; cleanup</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Agent rooms &amp; codegen</span><span class="example-topic">Persistence &amp; restore</span></div></li>
</ul>

```{toctree}
:hidden:

Pod boot the order is the product <01-pod-boot-the-order-is-the-product>
Persistence mesh your code their lanes <02-persistence-mesh-your-code-their-lanes>
Research sets lanes and residency <03-research-sets-lanes-and-residency>
Diffs are derived never stored <04-diffs-are-derived-never-stored>
Protocol crafter the tool that writes <05-protocol-crafter-the-tool-that-writes>
Two knobs and a terminator per rung <06-two-knobs-and-a-terminator-per-rung>
The codegen room agents writing code <07-the-codegen-room-agents-writing-code>
Research is graduated by room <08-research-is-graduated-by-room>
Getting data into your database <09-getting-data-into-your-database>
Deep overrides paths through a graph <10-deep-overrides-paths-through-a-graph>
Pointing a rift at your own frame <11-pointing-a-rift-at-your-own-frame>
The codegen loop end to end <12-the-codegen-loop-end-to-end>
One workshop many worlds <13-one-workshop-many-worlds>
Compositions a subsystem as one unit <14-compositions-a-subsystem-as-one-unit>
Campaigns the why that rides along <15-campaigns-the-why-that-rides-along>
Rewiring a running world <16-rewiring-a-running-world>
Notch swapping a live object <17-notch-swapping-a-live-object>
The package reads itself to you <18-the-package-reads-itself-to-you>
The codebase as a walkable graph <19-the-codebase-as-a-walkable-graph>
The workstation an agents workbench <20-the-workstation-an-agents-workbench>
Many agents writing code at once <21-many-agents-writing-code-at-once>
Asking what code would do before running it <22-asking-what-code-would-do-before-running-it>
Branching the record and joining back <23-branching-the-record-and-joining-back>
Loading a whole world back <24-loading-a-whole-world-back>
Many research sets one world <25-many-research-sets-one-world>
Codegen create modify iterate <26-codegen-create-modify-iterate>
A world that outlives its own runtime <27-a-world-that-outlives-its-own-runtime>
The record crosses as a json string <28-the-record-crosses-as-a-json-string>
Reading your own recorded code <29-reading-your-own-recorded-code>
Composing a version in the workshop <30-composing-a-version-in-the-workshop>
Organising lanes after the fact <31-organising-lanes-after-the-fact>
A subsystems blast radius <32-a-subsystems-blast-radius>
What a synthetic module actually is <33-what-a-synthetic-module-actually-is>
Several worlds of record in one process <34-several-worlds-of-record-in-one-process>
The gate that waits for readers <35-the-gate-that-waits-for-readers>
An agent builds a working system <36-an-agent-builds-a-working-system>
Review agent bindings <37-review-agent-bindings>
Named scopes in nexus and restore <38-named-scopes-in-nexus-and-restore>
```