# 🟠 Advanced examples

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

[Open the Advanced guide](../../advanced/index.md) · [All examples](../index.md)

<ul class="example-list">
<li class="example-item" data-level="advanced" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Lifetimes &amp; cleanup&quot;]" data-search="deep spell override paths deep override - the &quot;&gt;&quot;-path form. a path of parameter names walks the dependency graph from the melded root and replaces the actual object at that socket: override={&quot;transport&gt;credentials&quot;: my_object} untargeted sockets keep their di-resolved defaults within the call; a path that matches nothing refuses. but read the second half of this lesson before you reach for it: under a singleton lifetime the overridden meld builds the singleton, so the substitution outlives the call that made it. this is the surgical form - injecting a fixture or a variant into the middle of a real graph at meld time without rebinding anything. the simple top-level form (flat dict into the root&#x27;s own constructor) is intermediate lesson 08. meld(override={&quot;path&gt;to&gt;socket&quot;: object}) registration resolution lifetimes &amp; cleanup"><span class="example-level">🟠 Advanced · 01</span><h3><a href="01-deep-spell-override-paths.html">Deep spell override paths</a></h3><p>Deep override - the &quot;&gt;&quot;-path form. A path of parameter names walks the dependency graph from the melded root and REPLACES the actual object at that socket:…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Lifetimes &amp; cleanup</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Registration&quot;, &quot;Configuration&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="frames as worlds aetheric frames are worlds - the categories arc, act three. act 1 (beginner 25): spellframes categorize spells within a world. act 2 (intermediate 26): conduits categorize worlds of resolution. act 3: aetheric_frame= names an entire isolated world - its own registries, its own control plane, its own posture, its own singletons. and the line that wall does not cross, which is the real lesson: a frame is a world for instances and resolution. it is not a namespace for identity. a spell_id is the sha256 of the registered object&#x27;s code - its methods and constructor, its class-level values, its bases - and of nothing from the bind call. read that again and notice what is absent: the frame, the spellframe, the binding_name. so two books on two different frames binding the same class mint the same id, whatever names they give it, and the second registration is refused process-wide. moving to another frame is not a fix, and neither is another binding_name: one object is one spell. the fix is to make the classes different, not the worlds or the names: one subclass per world. a subclass is a new class, so a new spell_id, and every world can then keep it at the same address. once you do, everything you expect from a world wall holds - `unique` is one instance per frame, each world reuses its own singleton forever, and nothing leaks across. the other way is a regime, not a binding: with `process_wide_unique_spell_ids` turned off before the first frame exists, a spell_id is unique per frame, and one class may live in several worlds. that is aether configuration, and a lesson never installs it - lessons share one interpreter (advanced 07). the probe suite pins it in a reset world. why it is built this way: one spell_id names one spell, everywhere. an id that silently meant different things in different frames would make every checkpoint, every crystal and every research lane ambiguous the moment two frames existed. spellbook(aetheric_frame=...), one class per world at one address, per-frame instance isolation registration configuration persistence &amp; restore research &amp; change"><span class="example-level">🟠 Advanced · 02</span><h3><a href="02-frames-as-worlds.html">Frames as worlds</a></h3><p>Aetheric frames are WORLDS - the categories arc, act three. Act 1 (beginner 25): spellframes categorize spells WITHIN a world. Act 2 (intermediate 26): conduits categorize worlds of…</p><div><span class="example-topic">Registration</span><span class="example-topic">Configuration</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="advanced" data-topics="[&quot;Configuration&quot;]" data-search="frame posture public door frame posture through the public door. configure_aether_frame() is the manual fluent path: set the world&#x27;s system_state before anyone conjures, and every conjure then inherits it - no dynamic=true flag needed anywhere (the settle-then-inherit law from intermediate 21, driven from the configuration side this time). the posture freezes at the first conjure: configuring after that refuses - a world&#x27;s mode is decided once. spellbook(aetheric_frame=...), configure_aether_frame(system_state=...), plain-conjure inheritance, the freeze law configuration"><span class="example-level">🟠 Advanced · 03</span><h3><a href="03-frame-posture-public-door.html">Frame posture public door</a></h3><p>Frame POSTURE through the public door. configure_aether_frame() is the manual fluent path: set the world&#x27;s system_state BEFORE anyone conjures, and every conjure then INHERITS it - no…</p><div><span class="example-topic">Configuration</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;]" data-search="utility system logger logging through the aetherutilitysystem - the process-wide provider host every runtime object resolves its logger from. the boot law: melder boots silent. aether starts with a null safelogger and stays quiet until you attach something - no surprise stdout, no library spam. two public doors: aether.attach_logger(logger) - attach one real logger (stdlib logger or channel-style), or none to detach back to silence aether.enable_logging(logger) - attach explicitly, or with no argument try the configured automatic channel-logger policy runtime objects (books, conduits, the frames themselves) resolve their loggers through the utility system&#x27;s provider path. md.aether().attach_logger, enable_logging, the boots-silent law resolution configuration"><span class="example-level">🟠 Advanced · 04</span><h3><a href="04-utility-system-logger.html">Utility system logger</a></h3><p>Logging through the AetherUtilitySystem - the process-wide provider host every runtime object resolves its logger from. THE BOOT LAW: melder boots SILENT. Aether starts with a null…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span></div></li>
<li class="example-item" data-level="advanced" 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="frame posture cheatsheet the frame posture cheatsheet - every aethericframeconfiguration knob and what it does, in one runnable page (the advanced twin of beginner 37). the posture is the world&#x27;s law book: set before the first conjure, frozen by it, inherited by everyone after. mode system_state (&quot;automatic&quot;|&quot;dynamic&quot;) - the world&#x27;s mode. public doors: configure_aether_frame or first conjure(dynamic=true). ar eligibility (lived at the expert tier) ai_native_enabled - required true for dynamic ar targeting. rift_enabled - required true for any rift attachment. sharing shared_framewide_spellbook_configuration - one rich config shared by every book on the frame instead of per-book copies. caching system_caching_enabled - conjure-artifact caching. system_cache_root_path - where cached artifacts live. devops brakes (each one turns off a structural verb, world-wide) disable_linking / disable_bind / disable_conduit_cluster / disable_transfer_of_ownership / disable_contract_mutation / disable_mutations / disable_all_transactions_after_conjure - a gated verb refuses with a &quot;disabled&quot; runtimeerror at its own door. all seven are settable through the public door, configure_aether_frame(disable_linking=true, ...). transaction patience max_transaction_wait_time_in_seconds - how long a structural transaction waits on a busy scope before refusing, naming who held it. presets automatic_defaults() / dynamic_defaults() / with_defaults() the freeze law first successful bind of the posture freezes it. every with_* on a frozen posture refuses. one world, one law book. the posture vocabulary (reference lesson) registration configuration connections agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🟠 Advanced · 05</span><h3><a href="05-frame-posture-cheatsheet.html">Frame posture cheatsheet</a></h3><p>THE FRAME POSTURE CHEATSHEET - every AethericFrameConfiguration knob and what it does, in one runnable page (the advanced twin of beginner 37). The posture is the WORLD&#x27;s law book: set…</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="advanced" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;]" data-search="frame posture object the posture object itself. lesson 05 mapped the 14 knobs; this one picks the object up and handles it. the headline: this config is constructor-first, not fluent-first - alone among melder&#x27;s configs. four values are required keyword-only arguments at construction: origin_spellbook_id / system_state / ai_native_enabled / rift_enabled there is no bare aethericframeconfiguration(). you cannot start empty and fill it in. the world&#x27;s identity and mode are declared up front, and the with_* chain refines that declaration - it never originates it. that is the mechanical difference between this config and spellbookconfiguration, which you build empty and populate. three laws this lesson proves: 1. with_* mutates this object and returns self. it is fluent in shape, not in semantics - there is no copy, ever. the frame&#x27;s settlement law requires the retained object to be the bound one. 2. validate() raises; it does not return false. the bool return is a convention, not a verdict channel. ai_native_enabled requires system_state dynamic, and violating it is an exception. 3. finalize() freezes and returns the same instance - the fluent terminator. after it, every with_* refuses. md.aethericframeconfiguration (system_state passed as the string &quot;automatic&quot; / &quot;dynamic&quot;) resolution configuration agent rooms &amp; codegen research &amp; change"><span class="example-level">🟠 Advanced · 06</span><h3><a href="06-frame-posture-object.html">Frame posture object</a></h3><p>THE POSTURE OBJECT ITSELF. Lesson 05 mapped the 14 knobs; this one picks the object up and handles it. The headline: this config is CONSTRUCTOR-FIRST, not fluent-first - alone among…</p><div><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">Research &amp; change</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Research &amp; change&quot;]" data-search="aether config two doors two doors to one config, and the ladder behind them. aether hands you two ways to build its root configuration: aether.create_configuration() -&gt; aetherconfiguration aether.create_configuration_builder() -&gt; aetherconfigurationbuilder they are not redundant, and they do not end in the same place by accident - they end in the same place on purpose: config.with_*(...).finalize() -&gt; frozen builder.with_*(...).build() -&gt; frozen finalize() freezes and returns the same object. build() freezes and hands over ownership - it is one-shot and consuming, so the builder is spent afterwards. reach for the builder when construction happens somewhere that should not keep a handle on the result. the part everyone gets wrong: frozen is not ready. freezing and activating are two separate state bits, and this is the single most confusing thing about melder&#x27;s configuration model until you see it written down: frozen - &quot;no more edits&quot; (finalize / build / freeze) activated - &quot;in force&quot; (activate) a config can sit frozen for a long time before anything turns it on. so the ladder is three rungs, in this order, and the order is a rule rather than a convention: 1. finalize() or build() -&gt; frozen 2. configuration.activate() -&gt; activated 3. aether.activate(config) -&gt; aether itself comes up skipping rung 2 raises. aether&#x27;s own contract says so in capitals: &quot;the configuration must be activated before aether can be.&quot; the two failure modes stay distinct on purpose - &quot;not configured&quot; and &quot;configuration not activated&quot; are different sentences because they are different bugs. rung 3 is not performed here, deliberately. aether is a process-wide singleton, and `aether.activate(cfg)` installs the config before it checks the activated bit - so even the refusing call mutates the world. a lesson that shares an interpreter with every other lesson must not do that. the refusal is pinned in pytest_examples/test_advanced_probes.py, where the reset fixture owns a clean singleton. md.aether().create_configuration, create_configuration_builder, md.aetherconfiguration, md.aetherconfigurationbuilder, the freeze/activate split resolution configuration connections research &amp; change"><span class="example-level">🟠 Advanced · 07</span><h3><a href="07-aether-config-two-doors.html">Aether config two doors</a></h3><p>TWO DOORS TO ONE CONFIG, AND THE LADDER BEHIND THEM. Aether hands you two ways to build its root configuration: aether.create_configuration() -&gt; AetherConfiguration…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;]" data-search="nexus enablement turning the nexus on - and discovering that it does not climb the same ladder aether does. lesson 07 taught aether&#x27;s rule: freeze, then activate, then bring the subsystem up, in that order, or it refuses. nexus reaches the same destination by a different route, and knowing which subsystem you are talking to is the whole lesson. the nexus path nexus = md.nexus() # process-wide, no args config = nexus.create_configuration() nexus.activate(config) # installs and finalizes nexus.is_activated -&gt; true three asymmetries with aether, all real, none accidental: 1. the factory pre-defaults. aether&#x27;s create_configuration() hands back a bare config and you call with_defaults() yourself. nexus&#x27;s create_configuration() applies the default property set before returning. same verb shape, different starting state. 2. activate finalizes for you. aether refuses a merely-frozen config and makes you call configuration.activate() first - two bits, your responsibility. nexus.activate() finalizes the installed configuration on its way through. you do not pre-seal it, and trying to reason about it with aether&#x27;s rule in your head will mislead you. 3. neither factory installs. this one they agree on, and it is worth stating because it is the part people assume: create_* is a factory. it builds and hands over. nothing is wired anywhere until you pass it to activate(). two bits again, different names nexus.is_configured - a configuration is installed nexus.is_activated - the subsystem is up same shape as frozen/activated in lesson 07. configuration presence and subsystem liveness are always separate questions in melder. md.nexus, md.nexusconfiguration, create_configuration, activate, deactivate (frame mode passed as the string &quot;single&quot;) resolution configuration agent rooms &amp; codegen research &amp; change"><span class="example-level">🟠 Advanced · 08</span><h3><a href="08-nexus-enablement.html">Nexus enablement</a></h3><p>TURNING THE NEXUS ON - and discovering that it does NOT climb the same ladder Aether does. Lesson 07 taught Aether&#x27;s rule: freeze, then activate, then bring the subsystem up, in that order,…</p><div><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">Research &amp; change</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Agent rooms &amp; codegen&quot;]" data-search="opening a rift opening a rift - and meeting melder&#x27;s most repeated law for the third time in three lessons. the path (each step needs the one above it) nexus = md.nexus() nexus.activate(nexus.create_configuration()) # lesson 08 rift_config = nexus.create_rift_configuration() rift_config.with_space_type(&quot;static&quot;) rift = nexus.create_rift(configuration=rift_config, rift_name=&quot;ops&quot;) the rift configuration is consumed. create_rift() takes ownership. hand the same configuration to a second create_rift() and it refuses with &quot;riftconfiguration has already been consumed.&quot; one configuration, one rift - the same one-shot law aetherconfigurationbuilder.build() follows (lesson 07). if you want two rifts, you ask the factory twice. the law you have now seen three times melder never conflates &quot;this exists&quot; with &quot;this is live&quot;. every subsystem splits it into two bits, and only the names change: lesson 07 config frozen / activated lesson 08 nexus is_configured / is_activated lesson 09 rift is_registered / is_active once you have seen it three times it stops being trivia and starts being the thing you predict. when you meet a melder object you have never used, look for its two bits first - presence and liveness are always separate questions, and the answer to one never implies the other. what this lesson deliberately does not do: ar targeting. that needs `rift_enabled=true` on the target frame&#x27;s posture - the frame&#x27;s opt-in to being observable, and it defaults false. setting it is a frame concern, not a rift one, which is why it is not shown here: you posture the frame first, then attach. rifts, rooms and workstations are what this lesson covers. md.nexus.create_rift_configuration, create_rift, md.riftconfiguration, md.rift, md.riftspacetype resolution configuration agent rooms &amp; codegen"><span class="example-level">🟠 Advanced · 09</span><h3><a href="09-opening-a-rift.html">Opening a rift</a></h3><p>OPENING A RIFT - and meeting melder&#x27;s most repeated law for the third time in three lessons. THE PATH (each step needs the one above it) nexus = md.Nexus()…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Agent rooms &amp; codegen</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Registration&quot;, &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 room and its fixtures the room. every rift owns exactly one, and the law around it is stricter than people expect: a rift owns one primary room, its kind is chosen once at creation, and it is never switched. there is no room registry. there is no &quot;active space&quot;. there is no swap, promote, or re-type verb. `riftspacetype` is the single input that fixes a rift&#x27;s capability posture for life, and `rift` reads it at creation to construct the matching `riftspace` subclass. that is a design choice worth pausing on. a room you can re-type is a room whose permissions are a moving target, and every consumer holding a reference has to re-ask what it is allowed to do. fixing the kind at birth makes the answer cacheable and makes an audit of &quot;what can this rift do&quot; a question about creation, not about now. the fixtures - every room carries the same set, whatever its kind: space_id / space_name / owner_rift_id / space_kind / metadata frame_viewer - the read surface (type varies by kind) workstation - the binding canvas (lesson 12) command_system - the verb surface (type varies by kind) event_system - rift-local publish/subscribe memory_system - rift-local command/execution records action + category hooks - pre/post interception, unregister by id so every room has the same fixtures by name, and two of them differ by type: command_system and frame_viewer - what you may do and what you may see. the other three are literally the same classes. lesson 11 takes that pair apart. (an earlier draft of these lessons claimed only command_system varied; the owner&#x27;s 3.14t run proved frame_viewer varies too, and the corrected version is the better story - authority and visibility narrow together.) md.riftspace via rift.space, the room fixtures, the one-room law. room kind is passed as the string &quot;static&quot;; md.riftspacetype appears only in the doc-drift check below, where the enum itself is the subject. registration lifetimes &amp; cleanup configuration inspection agent rooms &amp; codegen research &amp; change"><span class="example-level">🟠 Advanced · 10</span><h3><a href="10-the-room-and-its-fixtures.html">The room and its fixtures</a></h3><p>THE ROOM. Every Rift owns exactly one, and the law around it is stricter than people expect: A RIFT OWNS ONE PRIMARY ROOM, ITS KIND IS CHOSEN ONCE AT CREATION, AND IT IS NEVER SWITCHED.…</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">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="advanced" data-topics="[&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;]" data-search="static vs capability authority what the room kind actually changes. staticriftspace and capabilityriftspace override exactly two properties of riftspace, and they are the two that matter: command_system staticcommandsystem / capabilitycommandsystem frame_viewer staticframeviewer / frameviewer the doing one and the seeing one. workstation, event_system and memory_system are inherited unchanged, so the room&#x27;s storage and signalling are constant while its authority and its visibility both narrow together. that pairing is the design. a room you may not mutate is also a room that shows you less - and melder does it the same way twice, by handing you a different class rather than guarding a shared one. and here is the design decision worth learning from. the static room does not refuse meld(). it does not raise permissionerror, it does not check a flag, it does not consult an acl at call time. it simply does not have the method. melder&#x27;s own note on staticcommandsystem says it outright: &quot;does not expose topology mutation or direct meld(...) because those methods now live on the capability surface instead of being denied after inheritance.&quot; that is the opposite of the usual pattern, where a subclass inherits everything and then overrides the dangerous half to raise. melder builds authority up by class membership instead of tearing it down by guard. why that is better, concretely: - there is no refusal path, so there is no refusal path to test, no error message to get subtly wrong, and no gap between &quot;the guard is there&quot; and &quot;the guard is correct&quot;. - capability becomes statically enumerable. you can answer &quot;what may this room do&quot; without executing anything and without triggering a single refusal. - hasattr becomes an honest question again. in a deny-after- inherit design it lies - the attribute is there and calling it explodes. the aix surface both kinds expose list_supported_command_methods(). a room will tell you what it can do. for an agent that is the difference between probing a surface by trying things and reading it. what moves between them static - reads, spell status, and meld_existing_spell (reuse of something already created; no creation, no topology) capability - all of that plus direct meld(), link/sever_link, create_lesser_conduit, and the cluster verbs (create/delete/join/leave/list) staticcommandsystem vs capabilitycommandsystem via room.command_system, list_supported_command_methods resolution lifetimes &amp; cleanup connections inspection agent rooms &amp; codegen research &amp; change"><span class="example-level">🟠 Advanced · 11</span><h3><a href="11-static-vs-capability-authority.html">Static vs capability authority</a></h3><p>WHAT THE ROOM KIND ACTUALLY CHANGES. StaticRiftSpace and CapabilityRiftSpace override exactly TWO properties of RiftSpace, and they are the two that matter: command_system…</p><div><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></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;]" data-search="the workstation canvas the workstation - the room&#x27;s binding canvas, and the last fixture in arc b. every riftspace owns one, whatever its kind. what it is: a room-local scratchpad that holds things across steps. what it is not, and this is the contract that matters: &quot;stores only room-local bindings; it does not discover or resolve new targets from melder/nexus.&quot; the workstation is not a resolver, not a registry, and not a second spellbook. it holds what you hand it. if you want something out of melder you get it through the command system (lesson 11) and then park it here. keeping those two jobs apart is why the canvas can be wiped without touching the world. three logical stores, kept separate on purpose: objects bind_object(name, value) attributes bind_attribute(name, value) methods bind_method(name, value) same name can live in two stores without collision, because `get` and `release` take a `store=` selector. one active target at a time set_target(name, store=...) select a saved binding as the target get_target() read it back call_target(*args) invoke it (optionally re-binding the result straight back onto the canvas) clear_target() deselect without deleting the binding &quot;at most one active target&quot; is a deliberate ceiling. a canvas with many simultaneous targets is a canvas where &quot;the target&quot; stops meaning anything. weak by request, and never by accident weak_ref=true force weak storage weak_ref=false force strong storage weak_ref=none use the room-local default captured at creation and the rule worth carrying to the rest of the library: &quot;explicit weak binding raises when the supplied value cannot be weak-referenced; it never silently degrades to strong storage.&quot; that is the same honesty you met at validate() in lesson 06, which raises instead of returning false. melder would rather fail loudly than quietly give you something adjacent to what you asked for. a silent degrade here would mean an object you believed was collectable is pinned for the life of the room - a leak that looks like correct code. md.workstation via room.workstation - bind_object, bind_method, get, release, describe_bindings, set_target/get_target/clear_target, weak_ref semantics registration resolution connections inspection agent rooms &amp; codegen"><span class="example-level">🟠 Advanced · 12</span><h3><a href="12-the-workstation-canvas.html">The workstation canvas</a></h3><p>THE WORKSTATION - the room&#x27;s binding canvas, and the last fixture in arc B. Every RiftSpace owns one, whatever its kind. WHAT IT IS: a room-local scratchpad that holds things across steps.…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</span><span class="example-topic">Connections</span><span class="example-topic">Inspection</span><span class="example-topic">Agent rooms &amp; codegen</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;, &quot;Concurrency&quot;]" data-search="the frame viewer facade the frame viewer - the room&#x27;s read surface, and the first place in melder where the aix claim stops being a design philosophy and becomes methods you can call. it is a facade, and it says so. frameviewer&#x27;s own docstrings read &quot;facade pass-through to viewmultiframe.list_frame_names(...)&quot; and note that it builds &quot;a viewmultiframe per invocation against a freshly resolved&quot; source. that second half matters more than the first: there is no cached snapshot. every read resolves fresh, so a viewer you held onto for an hour cannot hand you an hour-old world. you trade a little work per call for never having to ask &quot;is this stale?&quot; four specialized views behind it, in two groups get_view_multiframe() host-scoped - all frames, needs no name get_view_frame() frame-scoped - targets, visibility, topology get_view_conduit() frame-scoped - records, roots, relationships get_view_spell() frame-scoped - identity, source, binding and there is no default frame. the three frame-scoped accessors require a frame name, because &quot;the viewer no longer supports default-frame routing for frame-local operations&quot;. a freshly opened rift is contracted to no frames, so until you assign one there is no name to pass - and that is the honest state, not a bug in your code. signature defect found and fixed (2026-08-02): these were typed `frame_name: optional[str] = none` and then rejected none unconditionally - the documented default was never valid, so a reader who trusted the signature got an error for using it. 33 methods on frameviewer now declare `frame_name: str`, so omitting it fails at the call with a typeerror instead of inside the body. note the distinction that survived the fix, because it is real: frameviewer.describe_missing_surface(frame_name) selector, required viewframe.describe_missing_surface(frame_name=none) assertion, optional a viewframe is already bound to one frame, so naming it there is a guard against reading the wrong world, not a choice of which to read. optional is correct on one and a lie on the other. and then the part worth the whole lesson. the viewer carries a surface built for agents, by name: describe_agent_onboarding_json() how to use me describe_viewer_agent_purpose_json() what i am for describe_viewer_method_surface() what i can do list_viewer_method_names_ast_json() my methods, from the ast describe_viewer_class_surface_ast_json() most libraries expect a reader to arrive already knowing the api - docs live in a website, and the object tells you nothing about itself. these methods invert that. the object onboards its own caller, in json, at runtime. for a human that is a curiosity. for an agent it is the difference between guessing a surface and reading it - and it is the same idea as list_supported_command_methods() in lesson 11. twice now, melder has answered &quot;what may i do here?&quot; with a method instead of a manual. room.frame_viewer, get_view_* accessors, describe_available_views, describe_viewer_method_surface, describe_agent_onboarding_json registration resolution connections inspection agent rooms &amp; codegen research &amp; change concurrency"><span class="example-level">🟠 Advanced · 13</span><h3><a href="13-the-frame-viewer-facade.html">The frame viewer facade</a></h3><p>THE FRAME VIEWER - the room&#x27;s read surface, and the first place in melder where the AIX claim stops being a design philosophy and becomes methods you can call. IT IS A FACADE, AND IT SAYS…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</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="advanced" data-topics="[&quot;Registration&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;]" data-search="the describe ladder the describe ladder - why the read surface is not one fat describe() per thing, and why that shape is aimed at agents. look at what viewspell offers for a single spell: describe_spell_brief(...) the smallest useful answer describe_spell(...) the normal record describe_spell_detail(...) the long form describe_spell_payload(...) the raw payload ...and then nine per-facet verbs that hand you exactly one slice: describe_spell_identity describe_spell_source describe_spell_origin describe_spell_binding describe_spell_index describe_spell_resolution describe_spell_metadata describe_spell_research describe_spell_class_profile viewconduit is built the same way - brief / describe / topology / inventory / relationships / crosswalk, plus root and policy filters. this is a context budget control. a human reading one spell does not care whether the payload is 400 bytes or 40,000. an agent with a finite context window cares enormously. the ladder lets a caller enumerate 400 spells at brief, decide which three matter, and pay full price for only those three. a single fat describe() forces the opposite trade: either it is thin and you cannot answer detailed questions, or it is fat and surveying anything is unaffordable. the ladder refuses that choice. the cheap rung is always list_* list_spells / list_conduits / list_root_conduits names and ids first. descriptions only for what survives the filter. a note on this lesson&#x27;s world viewspell and viewconduit are frame-scoped (lesson 13), and a freshly opened rift is contracted to no frames - so this lesson maps the ladder off the exported types rather than off instances. that is not a workaround: the ladder is a property of the class. you do not need a populated world to see the shape of the surface you will be paying for, which is exactly the point of surveying before you commit. the host-scoped view (get_view_multiframe) needs no frame, so the cheapest rung of all really is callable before you have assigned anything - and this lesson proves that too. md.viewspell, md.viewconduit - the describe ladder, list_* enumeration, empty-world coherence registration connections inspection agent rooms &amp; codegen research &amp; change"><span class="example-level">🟠 Advanced · 14</span><h3><a href="14-the-describe-ladder.html">The describe ladder</a></h3><p>THE DESCRIBE LADDER - why the read surface is not one fat describe() per thing, and why that shape is aimed at agents. Look at what ViewSpell offers for a single spell:…</p><div><span class="example-topic">Registration</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></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Registration&quot;, &quot;Resolution&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Research &amp; change&quot;]" data-search="what you cannot see the read surface reports its own blind spots. arc c closes on the most unusual thing in the viewer family, and the most useful one if you are an agent. start from the problem. you call describe_spell(...) and a field is not there. what does that mean? (a) the field does not exist for this spell, or (b) it exists and this rift is not allowed to see it. melder states outright that you cannot tell from the outside: &quot;visibility-filtered projection: absence means &#x27;not visible to this rift&#x27; or &#x27;not present&#x27;, indistinguishable from outside.&quot; almost every api in existence stops there and leaves you to guess. for a human that produces a confused afternoon. for an agent it produces a confident wrong answer - &quot;this spell has no source binding&quot; instead of &quot;i was not shown the source binding&quot; - and the agent has no way to know which it said. so melder ships the disambiguator. describe_spell_missing_sections(...) viewspell describe_conduit_missing_sections(...) viewconduit describe_missing_surface(...) viewframe / frameviewer the spell one describes itself as &quot;the withheld-section probe: it computes every payload field name and subtracts the visible ones, so it reports the names of sections you cannot read. this is how you tell &#x27;hidden&#x27; from &#x27;empty&#x27; without the contents.&quot; read that last clause again - it is the whole design. you learn the shape of your blindness without breaching it. the contract says &quot;does not expose hidden payload bodies&quot;. so the probe is safe to ship to a low-authority room: it can honestly say &quot;there are three sections here you may not read&quot; without reading them. that is what makes this different from an error message. a refusal tells you that you were stopped. this tells you what you were stopped from, by name, without stopping being enforced any less. visible and missing are complements describe_visible_surface() what i can see right now describe_missing_surface() what i cannot together they partition the world. either alone is half an answer. and one anti-footgun worth stealing every one of these takes frame_name, and it is not a selector: &quot;`frame_name` is an assertion, not a selector - when supplied it must match the bound frame or the call raises.&quot; a parameter shaped like a filter that is really a guard. you cannot accidentally read a different frame than the one you think you are holding; saying the wrong name is an error, not a surprise result. describe_visible_surface / describe_missing_surface, describe_spell_missing_sections, describe_conduit_missing_sections registration resolution connections inspection agent rooms &amp; codegen research &amp; change"><span class="example-level">🟠 Advanced · 15</span><h3><a href="15-what-you-cannot-see.html">What you cannot see</a></h3><p>THE READ SURFACE REPORTS ITS OWN BLIND SPOTS. Arc C closes on the most unusual thing in the viewer family, and the most useful one if you are an agent. START FROM THE PROBLEM. You call…</p><div><span class="example-topic">Registration</span><span class="example-topic">Resolution</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></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Resolution&quot;, &quot;Connections&quot;]" data-search="ward policies ward policies - how permissive a conduit is about contracting with other conduits, and the three refusals that come with the door. a policy is broader than a visibility flag. it governs three control surfaces at once: - may this conduit initiate outbound grants? - may it accept inbound borrowed lineages? - are per-spell permission and whitelist checks enforced, or bypassed? five modes default both directions allowed, but every spell still has to satisfy its own permission and whitelist rules whitelist_all expose local lineages without per-spell whitelist flags, and let otherwise-blocked entries through block_all reject dynamic contracting from this ward entirely inbound_only accept borrowed inbound contracts; refuse to initiate outbound ones outbound_only grant outward; refuse inbound borrowing by peers three refusals, and the third is the interesting one 1. dynamic mode only. on an automatic frame the door raises. this is not a policy engine that sits idle in automatic mode - wards only form and sever contracts at runtime in dynamic mode, so outside it the setting would be decoration. 2. normal conduits only. a lesser conduit cannot hold a policy - &quot;convert to a normal conduit first&quot;. policy belongs to the thing that owns a lineage, not to a borrower of one. 3. no retroactive lockdown. setting block_all or whitelist_all while contracts exist raises. melder will not silently sever what you already granted, and it will not quietly leave the grants standing under a policy that says they should not exist. it refuses and makes you tear the contracts down yourself. that is the never-substitute rule (lessons 06/13/14/17) applied to authority: a policy change that cannot be honestly applied is an error, never a partial application. md.policies, conduit.set_new_policy, the dynamic-only / normal-only / no-existing-contracts refusals resolution connections"><span class="example-level">🟠 Advanced · 16</span><h3><a href="16-ward-policies.html">Ward policies</a></h3><p>WARD POLICIES - how permissive a conduit is about contracting with other conduits, and the three refusals that come with the door. A policy is broader than a visibility flag. It governs…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Connections</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Configuration&quot;, &quot;Connections&quot;, &quot;Inspection&quot;, &quot;Agent rooms &amp; codegen&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="taking a checkpoint taking a checkpoint - and settling which configuration ladder is the house rule. you have now seen three subsystems come up. lesson 07 aether you finalize, you activate the config, then aether.activate() - and handing it a merely-frozen config raises lesson 08 nexus you hand over a config and activate() finalizes it for you lesson 17 crystallizer ...follows aether. the crystallizer contract says it in the same capitals aether used: &quot;ordering rule: the configuration must be activated first... two distinct failure modes: &#x27;not configured&#x27; and &#x27;configuration not activated&#x27;.&quot; so it is two against one. caller-driven activation is the house rule; nexus is the exception. that is worth knowing before you meet a fourth subsystem - guess aether&#x27;s ladder and you will be right more often than not. and the builder here is the most generous in the library. crystallizerconfigurationbuilder offers three terminators, one per rung, so you choose where to get off: build() hand me the configuration finalize() ...frozen activate() ...and in force compare aetherconfigurationbuilder, which offers only build() and leaves rung 2 to you. same pattern, different generosity - which is exactly the kind of divergence the configuration-uniformity program exists to catalogue. the checkpoint door create_checkpoint(profile_name=none, description=none) -&gt; str it hands back an id. everything else keys off that id: list_checkpoint_ids() what exists describe_checkpoint(id) what is in one analyze_checkpoint(id) a deeper read verify_checkpoint_chain(...) is the lineage intact lesson 18 does the loading half. two bits, fifth appearance: activated / is_activated on the crystallizer, and `activated` on its configuration. by now you should expect it. md.crystallizer, md.crystallizerconfiguration, md.crystallizerconfigurationbuilder, create_checkpoint, list_checkpoint_ids, describe_checkpoint configuration connections inspection agent rooms &amp; codegen persistence &amp; restore research &amp; change"><span class="example-level">🟠 Advanced · 17</span><h3><a href="17-taking-a-checkpoint.html">Taking a checkpoint</a></h3><p>TAKING A CHECKPOINT - and settling which configuration ladder is the house rule. YOU HAVE NOW SEEN THREE SUBSYSTEMS COME UP. lesson 07 Aether you finalize, you activate the config, THEN…</p><div><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">Persistence &amp; restore</span><span class="example-topic">Research &amp; change</span></div></li>
<li class="example-item" data-level="advanced" data-topics="[&quot;Resolution&quot;, &quot;Configuration&quot;, &quot;Connections&quot;, &quot;Persistence &amp; restore&quot;, &quot;Research &amp; change&quot;]" data-search="loading it back the loading half - and the one place in melder where a successful return deliberately does not mean what you would assume. two places a checkpoint can live created an id exists in the running crystallizer cached it has been sealed to the local cache create_checkpoint() gives you the first. flush_checkpoint() moves it to the second - and, if a persistence manager is attached, tries to ship it onward too. flush_checkpoint(id=none) -&gt; list[str] seal, then ship list_cached_checkpoint_ids() what is sealed locally reload_cached_checkpoint(id) -&gt; dict read one back verify_checkpoint_chain(...) -&gt; dict is the lineage intact delete_cached_checkpoint(id) -&gt; str drop one now the two warnings, both from melder&#x27;s own contract. 1. a successful flush does not prove the remote received anything. &quot;the remote leg is lenient by default. under the default posture an [error is tolerated and] a successful return does not prove the remote received anything - the local seal is [what you actually get].&quot; everywhere else in this tier melder refuses rather than substituting (lessons 06/13/14/17/18). here it is deliberately lenient, and the reason is sound: a network you do not control should not be able to fail your local checkpoint. but it means flush() returning cleanly guarantees the local seal and nothing about the remote. if you need remote confirmation, the return value of flush() is not it. knowing which half of a two-part verb a return value covers is the difference between a backup and the belief in one. 2. flushing can evict something else. &quot;the fifo cap means an old cached checkpoint can be evicted as a side effect.&quot; so flush is not purely additive. the cache is bounded, and sealing a new checkpoint may silently retire your oldest. if a specific checkpoint matters, do not assume it is still cached - list_cached_checkpoint_ids() is the check, and it is cheap. the tier&#x27;s closing idea every lesson from 09 onward has been about the same discipline: know exactly what a call promises. two bits instead of one. names instead of contents. a refusal instead of a partial application. and here, at the end, a verb that is honest about covering two legs with different guarantees. flush_checkpoint, list_cached_checkpoint_ids, reload_cached_checkpoint, verify_checkpoint_chain, delete_cached_checkpoint resolution configuration connections persistence &amp; restore research &amp; change"><span class="example-level">🟠 Advanced · 18</span><h3><a href="18-loading-it-back.html">Loading it back</a></h3><p>THE LOADING HALF - and the one place in melder where a successful return deliberately does NOT mean what you would assume. TWO PLACES A CHECKPOINT CAN LIVE created an id exists in the…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Configuration</span><span class="example-topic">Connections</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="advanced" data-topics="[&quot;Resolution&quot;, &quot;Lifetimes &amp; cleanup&quot;]" data-search="wildcard and broadcast overrides the other two override forms. lesson 01 taught the path form - &quot;transport&gt;credentials&quot; - which names a socket exactly. there are three targeting forms in total, and melder states all of them: path a&gt;b&gt;c name the socket exactly unique *param &quot;there is exactly one of these, find it&quot; broadcast **param &quot;hit every one&quot; you still pass a plain dict to meld(override=...). the grammar lives in the key. why the other two exist a path requires you to know the shape of a graph you did not build. `*credentials` says &quot;somewhere below this root there is exactly one credentials socket - i do not care where&quot;. `**credentials` says &quot;there may be several and i mean all of them&quot;. and here is the part that makes them safe to use. the match counts are enforced, not advisory. *param requires exactly one match **param requires at least one match miss the count and resolution refuses. it does not apply your override to the first thing it found, and it does not quietly do nothing. melder&#x27;s own reasoning, which is worth reading twice: &quot;a `*param` that silently matched three sockets, or zero, would apply the caller&#x27;s intent to the wrong object or to nothing at all, and both fail invisibly at runtime rather than at resolution. failing loudly at map time is the whole point of resolving specs up front instead of during construction.&quot; that is the never-substitute rule (lessons 06/11/12/15/16) applied to targeting. a wildcard that guessed would be the worst kind of bug: your fixture lands on the wrong object and everything appears to work. precedence a `**param` broadcast and an exact `a&gt;b&gt;c` path can both name the same socket. when they overlap, specificity decides - the exact path wins over the broadcast. being more specific means being more authoritative, which is the only ordering that would not surprise someone. the lifetime rule still applies (lesson 01&#x27;s sharp edge) an override is surgical in where it reaches, not in how long it lasts. override into `unique` and you have changed the world. everything below is bound `many` so each meld builds its own graph and the fixtures cannot escape the call. meld(override={&quot;*param&quot;: obj}) and {&quot;**param&quot;: obj} resolution lifetimes &amp; cleanup"><span class="example-level">🟠 Advanced · 19</span><h3><a href="19-wildcard-and-broadcast-overrides.html">Wildcard and broadcast overrides</a></h3><p>THE OTHER TWO OVERRIDE FORMS. Lesson 01 taught the PATH form - &quot;transport&gt;credentials&quot; - which names a socket exactly. There are three targeting forms in total, and melder states all of…</p><div><span class="example-topic">Resolution</span><span class="example-topic">Lifetimes &amp; cleanup</span></div></li>
</ul>

```{toctree}
:hidden:

Deep spell override paths <01-deep-spell-override-paths>
Frames as worlds <02-frames-as-worlds>
Frame posture public door <03-frame-posture-public-door>
Utility system logger <04-utility-system-logger>
Frame posture cheatsheet <05-frame-posture-cheatsheet>
Frame posture object <06-frame-posture-object>
Aether config two doors <07-aether-config-two-doors>
Nexus enablement <08-nexus-enablement>
Opening a rift <09-opening-a-rift>
The room and its fixtures <10-the-room-and-its-fixtures>
Static vs capability authority <11-static-vs-capability-authority>
The workstation canvas <12-the-workstation-canvas>
The frame viewer facade <13-the-frame-viewer-facade>
The describe ladder <14-the-describe-ladder>
What you cannot see <15-what-you-cannot-see>
Ward policies <16-ward-policies>
Taking a checkpoint <17-taking-a-checkpoint>
Loading it back <18-loading-it-back>
Wildcard and broadcast overrides <19-wildcard-and-broadcast-overrides>
```