diff --git a/_config.yml b/_config.yml
index 772eca4..9aee543 100644
--- a/_config.yml
+++ b/_config.yml
@@ -77,12 +77,13 @@ exclude:
 
 # Every top level section is actually a collection. Their files are in a _folder in src/
 collections:
-  devguide:
+  java_devguide:
+    label: Java Developer Guide
     kind: docs
     output: true
-    name: "Developer Guide"
-    description: An ordered guide through SwimOS.
-    permalink: /developer-guide/:name/
+    name: "Java Developer Guide"
+    description: An ordered guide through SwimOS Java.
+    permalink: /java/developer-guide/:name/
     order:
       - index.md
       # 1. Introduction
@@ -99,12 +100,35 @@ collections:
       # 3.1 Agent URIs
       # 3.2 Agent Properties
       # 3.3 Traits
-  backend:
+  rust_devguide:
+    label: Rust Developer Guide
     kind: docs
     output: true
-    name: "Backend"
-    description: Documentation about SwimOS fundamentals and CLI usage.
-    permalink: /backend/:name/
+    name: "Rust Developer Guide"
+    description: An ordered guide through SwimOS Rust.
+    permalink: /rust/developer-guide/:name/
+    order:
+      - index.md
+      # 1. Introduction
+      - 1-introduction.md
+      # 2. Getting Started
+      - 2-getting-started.md
+      - 2.1-swim-create.md
+      - 2.2-project-setup.md
+      - 2.3-hello-world.md
+      - 2.4-hello-agent.md
+      - 2.5-hello-lane.md
+      # 3. Agents
+      # 3.1 Agent Details (parallel, atomic, no constructor, logging)
+      # 3.1 Agent URIs
+      # 3.2 Agent Properties
+      # 3.3 Traits
+  java_backend:
+    kind: docs
+    output: true
+    name: "Java Backend"
+    description: Documentation about SwimOS Java fundamentals and CLI usage.
+    permalink: /java/backend/:name/
     order:
       - index.md
       # Getting Started
@@ -151,6 +175,46 @@ collections:
       - recon.md
       - warp.md
     weight: 1
+  rust_backend:
+    kind: docs
+    output: true
+    name: "Rust Backend"
+    description: Documentation about SwimOS Rust fundamentals.
+    permalink: /rust/backend/:name/
+    order:
+      - index.md
+      # Getting Started
+      - fundamentals.md
+      - lane-organization.md
+      - agent-design.md
+      - swim-libraries.md
+      # Reference
+      - server.md
+      - web-agents.md
+      - lanes.md
+      - command-lanes.md
+      - value-lanes.md
+      - map-lanes.md
+      - join-value-lanes.md
+      - join-map-lanes.md
+      - demand-value-lanes.md
+      - demand-map-lanes.md
+      - planes.md
+      - links.md
+      - downlinks.md
+      - server-downlinks.md
+      - forms.md
+      - timers.md
+      - http-lanes.md
+      - persistence.md
+      # Swim Apps
+      - time-series.md
+      - summary-statistics.md
+      - aggregations.md
+      # Utilities
+      - cli.md
+      - introspection.md
+    weight: 1
   frontend:
     kind: docs
     output: true
@@ -181,10 +245,22 @@ collections:
       # Integrations
       # - react.md
     weight: 1
-  tutorials:
+  java_tutorials:
+    kind: docs
+    output: true
+    name: "Java Tutorials"
+    permalink: /java/tutorials/:name/
+    order:
+      - index.md
+      - demos.md
+      - transit.md
+      - monitor.md
+    weight: 2
+  rust_tutorials:
     kind: docs
     output: true
-    name: "Tutorials"
+    name: "Rust Tutorials"
+    permalink: /rust/tutorials/:name/
     order:
       - index.md
       - demos.md
@@ -221,7 +297,7 @@ defaults:
 toc:
   list_id: toc # id of the <ul> for the toc
   list_class: mt-1 px-2 # We use TailwindCSS classes but you can also create your own
-  sublist_class: '' # We use TailwindCSS classes but you can also create your own
+  sublist_class: "" # We use TailwindCSS classes but you can also create your own
   item_class: hover:text-swim-blue block rounded-md py-2 pr-2 pl-9 text-sm leading-6 text-swim-body-text # You guessed it, more TailwindCSS classes.
   item_prefix: toc- # Adds a toc-* class to each list item for styling. Ex. toc-h2 for list items that refer to an h2 in the doc body.
 
@@ -235,8 +311,10 @@ announcement:
 
 feed:
   collections:
-    - tutorials
-    - backend
+    - java_tutorials
+    - java_backend
+    - rust_tutorials
+    - rust_backend
     - meta
 
 paginate: 9
diff --git a/_data/header-nav.yml b/_data/header-nav.yml
index 6fb8986..f8a5e05 100644
--- a/_data/header-nav.yml
+++ b/_data/header-nav.yml
@@ -47,36 +47,45 @@
 - section: Documentation
   id: documentation
   menu:
-    - group: Backend
+    - group: Java Backend
       items:
         - title: Backend Documentation
-          blurb: 
+          blurb:
           icon: "fa-solid fa-server"
-          url: /backend/
+          url: /java/backend/
         - title: Developer Guide
-          blurb: Learn SwimOS from the start
+          blurb: Learn SwimOS Java from the start
+          icon: "fa-brands fa-java"
+          url: /java/developer-guide/
+        - title: Tutorials
+          blurb:
+          icon: "fa-solid fa-graduation-cap"
+          url: /java/tutorials/
+    - group: Rust Backend
+      items:
+        - title: Backend Documentation
+          blurb:
+          icon: "fa-solid fa-server"
+          url: /rust/backend/
+        - title: Rust Developer Guide
+          blurb: Learn SwimOS Rust from the start
           icon: "fa-brands fa-java"
-          url: /developer-guide/
+          url: /rust/developer-guide/
+        - title: Tutorials
+          blurb:
+          icon: "fa-solid fa-graduation-cap"
+          url: /rust/tutorials/
     - group: Frontend
       items:
         - title: Frontend Documentation
-          blurb: 
+          blurb:
           icon: "fa-solid fa-code"
           url: /frontend/
-    - group: Tutorials & Blog
-      items:
-        - title: Tutorials
-          blurb:
-          icon: "fa-solid fa-graduation-cap"
-          url: /tutorials/
-        - title: Blog
-          blurb: 
-          icon: "fa-solid fa-rss"
-          url: /blog/
+
     # - group: Frontend
     #   items:
     #     - title: Swim UI Documentation
-    #       blurb: 
+    #       blurb:
     #       icon: "fa-solid fa-display"
     #       url: /frontend/
   more:
@@ -91,10 +100,10 @@
   menu:
     - group: Code
       items:
-      - title: GitHub
-        blurb: Check out Swim’s latest projects and commits on GitHub.
-        icon: "fa-brands fa-github"
-        url: https://github.com/swimos/swim
+        - title: GitHub
+          blurb: Check out Swim's latest projects and commits on GitHub.
+          icon: "fa-brands fa-github"
+          url: https://github.com/swimos/swim
       # Java Doc & JS info is updated in header.html
     - group: Contribute
       items:
@@ -103,7 +112,7 @@
           icon: "fa-solid fa-bug"
           url: https://github.com/swimos/swim/issues/new
         - title: Code of Conduct
-          blurb: 
+          blurb:
           icon: "fa-solid fa-people-roof"
           url: https://github.com/swimos/swimos-docs/blob/main/CODE_OF_CONDUCT.md
         - title: Contributor's Guide
diff --git a/_data/rust-crates.yml b/_data/rust-crates.yml
new file mode 100644
index 0000000..0d1a03d
--- /dev/null
+++ b/_data/rust-crates.yml
@@ -0,0 +1,7 @@
+# SwimOS crates
+swimos-version: 0.1.0
+swimos-client-version: 0.1.0
+swimos-form-version: 0.1.0
+
+# Support crates
+tokio-version: 1.3
diff --git a/_includes/docs-categories.html b/_includes/docs-categories.html
index 7cb6e14..11072c7 100644
--- a/_includes/docs-categories.html
+++ b/_includes/docs-categories.html
@@ -2,11 +2,13 @@
 <div class="mx-auto mt-32 max-w-7xl sm:px-6 lg:px-8">
     <div class="mx-auto max-w-7xl px-6 lg:px-8">
         <div class="max-w-2xl mb-8">
-            <h3 class="flex items-center text-2xl sm:text-3xl font-semibold leading-8 text-kaimurasaki-800">SwimOS Reference</h3>
+            <h3 class="flex items-center text-2xl sm:text-3xl font-semibold leading-8 text-kaimurasaki-800">SwimOS
+                Reference</h3>
             <!-- <div class="mt-2 text-lg leading-8 text-kaimurasaki-700">?</div> -->
-          </div>
+        </div>
         <ul role="list" class="grid grid-cols-1 gap-x-10 gap-y-12 lg:grid-cols-3 xl:gap-x-12">
-            <li class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-purple bg-swim-dark-blue text-white">
+            <li
+                class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-purple bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
                     <svg xmlns="http://www.w3.org/2000/svg" fill="#BA62FF" viewBox="0 0 448 512" stroke-width="2"
                         stroke="currentColor"
@@ -22,14 +24,15 @@ <h3 class="flex items-center text-2xl sm:text-3xl font-semibold leading-8 text-k
                         Learn how to build stateful backend services for streaming data applications.
                     </p>
                     <div class="mt-10 mb-10 pt-12 text-center">
-                        <a href="{% link _backend/index.md %}"
+                        <a href="{% link _java_backend/index.md %}"
                             class="no-underline rounded-full px-4 py-2.5 text-sm font-semibold text-white shadow-sm ring-1 ring-inset ring-white hover:bg-white hover:text-swim-dark-blue">Get
                             started</a>
                     </div>
                 </div>
             </li>
 
-            <li class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-teal bg-swim-dark-blue text-white">
+            <li
+                class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-teal bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
                     <svg xmlns="http://www.w3.org/2000/svg" fill="#66FFDD" viewBox="0 0 512 512" stroke-width="2"
                         stroke="currentColor"
@@ -45,14 +48,15 @@ <h3 class="flex items-center text-2xl sm:text-3xl font-semibold leading-8 text-k
                         Learn how to build real-time user interfaces for streaming data applications.
                     </p>
                     <div class="mt-10 mb-10 pt-12 text-center">
-                        <a href="{% link _backend/index.md %}"
+                        <a href="{% link _java_backend/index.md %}"
                             class="no-underline rounded-full px-4 py-2.5 text-sm font-semibold text-white shadow-sm ring-1 ring-inset ring-white hover:bg-white hover:text-swim-dark-blue">Get
                             started</a>
                     </div>
                 </div>
             </li>
 
-            <li class=" flex flex-col justify-between overflow-hidden rounded-xl border border-swim-blue bg-swim-dark-blue text-white">
+            <li
+                class=" flex flex-col justify-between overflow-hidden rounded-xl border border-swim-blue bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
 
                     <svg xmlns="http://www.w3.org/2000/svg" fill="#32C5FF" viewBox="0 0 640 512" stroke-width="2"
diff --git a/_layouts/documentation.html b/_layouts/documentation.html
index 89c0ede..5f944ce 100644
--- a/_layouts/documentation.html
+++ b/_layouts/documentation.html
@@ -1,47 +1,57 @@
 <!doctype html>
-<html class="w-screen min-h-full scroll-pt-[calc(48px+20px)] lg:scroll-pt-[calc(60px+20px)] bg-white scroll-smooth" lang="{{ page.lang | default: site.lang | default: 'en' }}">
-  {%- include head.html -%}
-  {%- include docs-feedback-widget.html -%}
-  <body class="overflow-x-hidden">
-    {% include google-tag-noscript.html %}
-    <div class="flex flex-wrap items-start bg-white">
-      <!-- Header -->
-      {%- include banner.html -%}
-      {%- include header.html sticky=false -%}
-      {%- include docs-header.html sticky=true -%}
+<html class="w-screen min-h-full scroll-pt-[calc(48px+20px)] lg:scroll-pt-[calc(60px+20px)] bg-white scroll-smooth"
+  lang="{{ page.lang | default: site.lang | default: 'en' }}">
+{%- include head.html -%}
+{%- include docs-feedback-widget.html -%}
 
-      <!-- Left margin -->
-      <div class="{% if page.toc %}grow lg:grow-0 xl:grow basis-[1px] lg:basis-4{% else %}grow-0 xl:grow lg:basis-4{% endif %}"></div>
-      <!-- Sidebar -->
-      <aside class="hidden lg:block lg:top-[60px] lg:w-[224px] lg:py-10 overflow-x-none overflow-y-auto">
-        {%- include docs-sidebar.html -%}
-      </aside>
+<body class="overflow-x-hidden">
+  {% include google-tag-noscript.html %}
+  <div class="flex flex-wrap items-start bg-white">
+    <!-- Header -->
+    {%- include banner.html -%}
+    {%- include header.html sticky=false -%}
+    {%- include docs-header.html sticky=true -%}
 
-      <!-- Main content -->
-      <main class="w-screen{% if page.toc %} max-w-[768px] lg:w-[784px] lg:max-w-[784px] xl:w-[800px] xl:max-w-[800px] grow lg:grow-0{% else %} max-w-[1024px] xl:w-[1024px] lg:basis-0 xl:basis-auto grow xl:grow-0{% endif %} px-6{% if page.toc %} lg:px-8 xl:px-10{% else %} lg:pl-8 lg:pr-4 xl:pl-10{% endif %} py-10 lg:mb-14 prose prose-code:before:hidden prose-code:after:hidden">
-        <h1 class="text-swim-dark-blue">{{ page.title }}</h1>
-        {{ content | inject_anchors }}
-        <hr class="mb-0 border-t-vermilion"/>
-        {%- include prev-next.html -%}
-      </main>
+    <!-- Left margin -->
+    <div
+      class="{% if page.toc %}grow lg:grow-0 xl:grow basis-[1px] lg:basis-4{% else %}grow-0 xl:grow lg:basis-4{% endif %}">
+    </div>
+    <!-- Sidebar -->
+    <aside class="hidden lg:block lg:top-[60px] lg:w-[224px] lg:py-10 overflow-x-none overflow-y-auto">
+      {%- include docs-sidebar.html -%}
+    </aside>
+
+    <!-- Main content -->
+    <main
+      class="w-screen{% if page.toc %} max-w-[768px] lg:w-[784px] lg:max-w-[784px] xl:w-[800px] xl:max-w-[800px] grow lg:grow-0{% else %} max-w-[1024px] xl:w-[1024px] lg:basis-0 xl:basis-auto grow xl:grow-0{% endif %} px-6{% if page.toc %} lg:px-8 xl:px-10{% else %} lg:pl-8 lg:pr-4 xl:pl-10{% endif %} py-10 lg:mb-14 prose prose-code:before:hidden prose-code:after:hidden">
+      <h1 class="text-swim-dark-blue">{{ page.title }}</h1>
+      {{ content | inject_anchors }}
+      <hr class="mb-0 border-t-vermilion" />
+      {%- include prev-next.html -%}
+    </main>
 
     {% if page.toc %}
-      <!-- Table of contents -->
-      <aside class="hidden xl:block xl:sticky xl:top-[60px] xl:w-[224px] xl:max-h-[calc(100vh-60px)] xl:py-10 overflow-x-none overflow-y-auto">
-        <div x-data @scroll.window="updateActiveSection">
-          <h2 class="flex items-center text-xs font-medium leading-6 tracking-wider uppercase text-kaimurasaki-800">On this page</h2>
-          {% toc %}
-        </div>
-      </aside>
+    <!-- Table of contents -->
+    <aside
+      class="hidden xl:block xl:sticky xl:top-[60px] xl:w-[224px] xl:max-h-[calc(100vh-60px)] xl:py-10 overflow-x-none overflow-y-auto">
+      <div x-data @scroll.window="updateActiveSection">
+        <h2 class="flex items-center text-xs font-medium leading-6 tracking-wider uppercase text-kaimurasaki-800">On
+          this page</h2>
+        {% toc %}
+      </div>
+    </aside>
     {% endif %}
-      <!-- Right margin -->
-      <div class="{% if page.toc %}grow lg:grow-0 xl:grow basis-[1px] xl:basis-4{% else %}grow-0 xl:grow lg:basis-4{% endif %}"></div>
-
-      <!-- Footer -->
-      {%- include footer.html -%}
+    <!-- Right margin -->
+    <div
+      class="{% if page.toc %}grow lg:grow-0 xl:grow basis-[1px] xl:basis-4{% else %}grow-0 xl:grow lg:basis-4{% endif %}">
     </div>
-    {%- include footer-scripts.html -%}
-    
-  </body>
-  <script src="/assets/js/copy-code.js"></script>
+
+    <!-- Footer -->
+    {%- include footer.html -%}
+  </div>
+  {%- include footer-scripts.html -%}
+
+</body>
+<script src="/assets/js/copy-code.js"></script>
+
 </html>
\ No newline at end of file
diff --git a/index.html b/index.html
index d4e3313..8a03cca 100644
--- a/index.html
+++ b/index.html
@@ -77,7 +77,7 @@ <h2 class="text-sm font-semibold leading-7 text-swim-teal">Proven at scale</h2>
             </div>
 
             <div class="mt-10 flex items-center gap-x-6">
-                <a href="{% link _devguide/index.md %}"
+                <a href="{% link _java_devguide/index.md %}"
                     class="no-underline rounded-full bg-swim-dark-blue px-4 py-2.5 text-sm font-semibold text-swim-teal shadow-sm ring-1 ring-inset ring-swim-teal hover:bg-swim-teal hover:text-swim-dark-blue">Get
                     started</a>
                 <a href="#demos" class="text-sm font-semibold leading-6 text-swim-teal no-underline hover:underline">See
@@ -128,7 +128,8 @@ <h2 class="text-sm font-semibold leading-7 text-swim-teal">Proven at scale</h2>
 <div class="mx-auto mt-32 max-w-7xl sm:px-6 lg:px-8">
     <div class="mx-auto max-w-7xl px-6 lg:px-8">
         <ul role="list" class="grid grid-cols-1 gap-x-10 gap-y-12 lg:grid-cols-3 xl:gap-x-12">
-            <li class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-purple bg-swim-dark-blue text-white">
+            <li
+                class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-purple bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
                     <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2"
                         stroke="currentColor"
@@ -141,17 +142,19 @@ <h2 class="text-sm font-semibold leading-7 text-swim-teal">Proven at scale</h2>
                 <div class="px-6 py-4 pt-12 leading-6">
                     <h3 class="font-bold text-white">Get started with SwimOS</h3>
                     <p class="mt-2 text-sm">
-                        Follow these tutorials to create a SwimOS project step by step to learn the basics and get up and running.
+                        Follow these tutorials to create a SwimOS project step by step to learn the basics and get up
+                        and running.
                     </p>
                     <div class="mt-10 mb-10 pt-12 text-center">
-                        <a href="{% link _tutorials/index.md %}"
+                        <a href="{% link _java_tutorials/index.md %}"
                             class="no-underline rounded-full px-4 py-2.5 text-sm font-semibold text-white shadow-sm ring-1 ring-inset ring-white hover:bg-white hover:text-swim-dark-blue">Get
                             started</a>
                     </div>
                 </div>
             </li>
 
-            <li class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-teal bg-swim-dark-blue text-white">
+            <li
+                class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-teal bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
                     <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2"
                         stroke="currentColor"
@@ -164,17 +167,19 @@ <h3 class="font-bold text-white">Get started with SwimOS</h3>
                 <div class="px-6 py-4 pt-12 leading-6">
                     <h3 class="font-bold text-white">Learn streaming data concepts</h3>
                     <p class="mt-2 text-sm">
-                        Learn concepts and ideas that will help you understand how SwimOS fits in to your existing infrastructure.
+                        Learn concepts and ideas that will help you understand how SwimOS fits in to your existing
+                        infrastructure.
                     </p>
                     <div class="mt-10 mb-10 pt-12 text-center">
-                        <a href="{% link _backend/index.md %}"
+                        <a href="{% link _java_backend/index.md %}"
                             class="no-underline rounded-full px-4 py-2.5 text-sm font-semibold text-white shadow-sm ring-1 ring-inset ring-white hover:bg-white hover:text-swim-dark-blue">Get
                             started</a>
                     </div>
                 </div>
             </li>
 
-            <li class=" flex flex-col justify-between overflow-hidden rounded-xl border border-swim-blue bg-swim-dark-blue text-white">
+            <li
+                class=" flex flex-col justify-between overflow-hidden rounded-xl border border-swim-blue bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
                     <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2"
                         stroke="currentColor"
@@ -187,7 +192,8 @@ <h3 class="font-bold text-white">Learn streaming data concepts</h3>
                 <div class="px-6 py-4 pt-12 leading-6">
                     <h3 class="font-bold text-white">Learn by example</h3>
                     <p class="mt-2 text-sm">
-                        Tinker with our executable cookbook examples to learn SwimOS concepts and tinker with streaming data.
+                        Tinker with our executable cookbook examples to learn SwimOS concepts and tinker with streaming
+                        data.
                     </p>
                     <div class="mt-10 mb-10 pt-12 text-center">
                         <a href="https://github.com/swimos/cookbook"
@@ -197,7 +203,8 @@ <h3 class="font-bold text-white">Learn by example</h3>
                 </div>
             </li>
 
-            <li class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-blue bg-swim-dark-blue text-white">
+            <li
+                class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-blue bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
                     <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2"
                         stroke="currentColor"
@@ -213,14 +220,15 @@ <h3 class="font-bold text-white">Take a guided tour of SwimOS</h3>
                         This developer guide will help you learn SwimOS from the start.
                     </p>
                     <div class="mt-10 mb-10 pt-12 text-center">
-                        <a href="{% link _devguide/index.md %}"
+                        <a href="{% link _java_devguide/index.md %}"
                             class="no-underline rounded-full px-4 py-2.5 text-sm font-semibold text-white shadow-sm ring-1 ring-inset ring-white hover:bg-white hover:text-swim-dark-blue">Get
                             started</a>
                     </div>
                 </div>
             </li>
 
-            <li class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-purple bg-swim-dark-blue text-white">
+            <li
+                class="flex flex-col justify-between overflow-hidden rounded-xl border border-swim-purple bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
                     <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2"
                         stroke="currentColor"
@@ -236,14 +244,15 @@ <h3 class="font-bold text-white">Learn how SwimOS works</h3>
                         Refer to our reference documentation to see how SwimOS works under the hood
                     </p>
                     <div class="mt-10 mb-10 pt-12 text-center">
-                        <a href="{% link _backend/index.md %}"
+                        <a href="{% link _java_backend/index.md %}"
                             class="no-underline rounded-full px-4 py-2.5 text-sm font-semibold text-white shadow-sm ring-1 ring-inset ring-white hover:bg-white hover:text-swim-dark-blue">Get
                             started</a>
                     </div>
                 </div>
             </li>
 
-            <li class=" flex flex-col justify-between overflow-hidden rounded-xl border border-swim-teal bg-swim-dark-blue text-white">
+            <li
+                class=" flex flex-col justify-between overflow-hidden rounded-xl border border-swim-teal bg-swim-dark-blue text-white">
                 <div class="flex items-center gap-x-4 border-b border-gray-900/5 p-6">
                     <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2"
                         stroke="currentColor"
@@ -402,10 +411,10 @@ <h2 class="text-3xl font-bold tracking-tight text-swim-dark-blue sm:text-4xl">
                 Get started with our developer guide.
             </h2>
             <div class="mt-10 flex items-center gap-x-6 lg:mt-0 lg:flex-shrink-0">
-                <a href="{% link _devguide/index.md %}"
+                <a href="{% link _java_devguide/index.md %}"
                     class="no-underline rounded-full bg-swim-dark-blue px-4 py-2.5 text-sm font-semibold text-white shadow-sm ring-1 ring-inset ring-white hover:bg-swim-teal hover:text-swim-dark-blue">Get
                     started</a>
-                <a href="{% link _backend/index.md %}"
+                <a href="{% link _java_backend/index.md %}"
                     class="text-sm font-semibold leading-6 text-swim-dark-blue no-underline hover:underline">View
                     Reference
                     Docs
diff --git a/src/_frontend/downlinks.md b/src/_frontend/downlinks.md
index 3881e63..d63ff0e 100644
--- a/src/_frontend/downlinks.md
+++ b/src/_frontend/downlinks.md
@@ -9,7 +9,7 @@ redirect_from:
 
 {% include alert.html title='Version Note' text='This documentation describes Swim JS packages v4.0.0-dev-20230923 or later. Users of earlier package versions may experience differences in behavior.' %}
 
-A Downlink provides a virtual bidirectional stream between the client and a lane of a remote Web Agent. WARP clients transparently multiplex all links to [**Web Agents**]({% link _backend/web-agents.md %}) on a given host over a single WebSocket connection.
+A Downlink provides a virtual bidirectional stream between the client and a lane of a remote Web Agent. WARP clients transparently multiplex all links to [**Web Agents**]({% link _java_backend/web-agents.md %}) on a given host over a single WebSocket connection.
 
 Downlinks come in several flavors, depending on the WARP subprotocol to which they conform. A [**ValueDownlink**]({% link _frontend/valueDownlink.md %}) synchronizes a value with a remote value lane. A [**MapDownlink**]({% link _frontend/mapDownlink.md %}) implements the WARP map subprotocol to synchronize key-value state with a remote map lane. And an [**EventDownlink**]({% link _frontend/eventDownlink.md %}) observes raw WARP events, and can be used to observe lanes of any kind.
 
@@ -18,11 +18,12 @@ This article will focus on the properties and methods which all types of downlin
 ## Addressing Downlinks
 
 Before opening, a downlink must be addressed with the `hostUri`, `nodeUri`, and `laneUri` to which it should connect.
-* The `hostUri` is the domain name of the host application. It must always be prepended by either `warp://` or `warps://`.
-* The `nodeUri` is the path to the Web Agent to which you wish to connect. If following our [**recommended design**]({% link _backend/agent-design.md %}), Web Agents will represent identifiable domain elements (think, a noun) and include the name of the entity type in the node URI, possibly alongside an ID (e.g. `/hotel/room/:roomId`).
-* The `laneUri` is the most specific part of a downlink's address. A lane exposes a subset of a Web Agent's properties and methods. Lane content will vary greatly from lane to lane and will be heavily influenced by the subtype of lane to which it conforms.
 
-For an overview of Web Agents, lanes, and the general structure of a Swim application, visit [**SwimOS Concepts**]({% link _backend/fundamentals.md %}).
+- The `hostUri` is the domain name of the host application. It must always be prepended by either `warp://` or `warps://`.
+- The `nodeUri` is the path to the Web Agent to which you wish to connect. If following our [**recommended design**]({% link _java_backend/agent-design.md %}), Web Agents will represent identifiable domain elements (think, a noun) and include the name of the entity type in the node URI, possibly alongside an ID (e.g. `/hotel/room/:roomId`).
+- The `laneUri` is the most specific part of a downlink's address. A lane exposes a subset of a Web Agent's properties and methods. Lane content will vary greatly from lane to lane and will be heavily influenced by the subtype of lane to which it conforms.
+
+For an overview of Web Agents, lanes, and the general structure of a Swim application, visit [**SwimOS Concepts**]({% link _java_backend/fundamentals.md %}).
 
 The simplest and most common way to address a downlink is to pass an options object with the `hostUri`, `nodeUri`, and `laneUri` during initialization.
 
@@ -31,12 +32,11 @@ import { WarpClient } from "@swim/client";
 
 const client = new WarpClient();
 // set address within the downlink
-const hvacDownlink = client
-  .downlink({
-    hostUri: "warp://example.com",
-    nodeUri: "/hotel/room/123",
-    laneUri: "hvac",
-  });
+const hvacDownlink = client.downlink({
+  hostUri: "warp://example.com",
+  nodeUri: "/hotel/room/123",
+  laneUri: "hvac",
+});
 ```
 
 Additionally, all or part of a downlink's address can be inherited from the `WarpClient` which is being used to open the downlink. This approach can be useful to avoid repeating oneself or when working with a large number of links.
@@ -46,10 +46,9 @@ const client = new WarpClient();
 client.hostUri.set("warp://example.com");
 client.nodeUri.set("/hotel/room/123");
 // inherit hostUri and nodeUri defined on client
-const lightingDownlink = client
-  .downlink({
-    laneUri: "lighting",
-  });
+const lightingDownlink = client.downlink({
+  laneUri: "lighting",
+});
 ```
 
 ## Other Options
@@ -62,14 +61,13 @@ The `syncs` parameter determines whether or not a downlink should synchronize wi
 
 ```javascript
 const client = new WarpClient();
-const hvacDownlink = client
-  .downlink({
-    hostUri: "warp://example.com",
-    nodeUri: "/hotel/room/123",
-    laneUri: "hvac",
-    relinks: true, // will automatically attempt to reconnect after a network failure
-    syncs: false, // will not sychronize with remote lane state when opened; updates only
-  });
+const hvacDownlink = client.downlink({
+  hostUri: "warp://example.com",
+  nodeUri: "/hotel/room/123",
+  laneUri: "hvac",
+  relinks: true, // will automatically attempt to reconnect after a network failure
+  syncs: false, // will not sychronize with remote lane state when opened; updates only
+});
 ```
 
 ## Opening a Downlink
@@ -82,7 +80,7 @@ const downlink = client
   .downlink({
     hostUri: "warp://example.com",
     nodeUri: "/hotel/floor/1",
-    laneUri: "status"
+    laneUri: "status",
   })
   .open();
 
@@ -102,17 +100,26 @@ The `connected` method returns `true` if the underlying connection to the remote
 Here is an example of a downlink being opened with some registered callbacks for listening to connection status.
 
 ```javascript
-const downlink = client.current.downlink({
-  hostUri: "warp://example.com",
-  nodeUri: "hotel/room/123",
-  laneUri: "status",
-  didConnect: () => { console.log("didConnect"); },
-  didDisconnect: () => { console.log("didDisconnect"); },
-  didClose: () => { console.log("didClose"); },
-})
-.open();
+const downlink = client.current
+  .downlink({
+    hostUri: "warp://example.com",
+    nodeUri: "hotel/room/123",
+    laneUri: "status",
+    didConnect: () => {
+      console.log("didConnect");
+    },
+    didDisconnect: () => {
+      console.log("didDisconnect");
+    },
+    didClose: () => {
+      console.log("didClose");
+    },
+  })
+  .open();
 
-setTimeout(() => { downlink.close(); }, 1000);
+setTimeout(() => {
+  downlink.close();
+}, 1000);
 
 /* Output:
   didConnect
@@ -122,15 +129,22 @@ setTimeout(() => { downlink.close(); }, 1000);
 Here is what the same example would look like if, instead of calling `downlink.close()`, the client began to experience network issues or if the host suddenly went offline.
 
 ```javascript
-const downlink = client.current.downlink({
-  hostUri: "warp://example.com",
-  nodeUri: "hotel/room/123",
-  laneUri: "status",
-  didConnect: () => { console.log("didConnect"); },
-  didDisconnect: () => { console.log("didDisconnect"); },
-  didClose: () => { console.log("didClose"); },
-})
-.open();
+const downlink = client.current
+  .downlink({
+    hostUri: "warp://example.com",
+    nodeUri: "hotel/room/123",
+    laneUri: "status",
+    didConnect: () => {
+      console.log("didConnect");
+    },
+    didDisconnect: () => {
+      console.log("didDisconnect");
+    },
+    didClose: () => {
+      console.log("didClose");
+    },
+  })
+  .open();
 
 /* (some network issues) */
 
@@ -143,11 +157,11 @@ In the case that a downlink attempts to connect with a node (web agent) or lane
 
 ```javascript
 // WARP message received after network connection issue
-"@unlink(node:\"/hotel/room/123\",lane:status)"
+"@unlink(node:\"/hotel/room/123\",lane:status)";
 // WARP message received after web agent not found
-"@unlinked(node:\"/hotel/room/invalid_room_number\",lane:status)@nodeNotFound"
+"@unlinked(node:\"/hotel/room/invalid_room_number\",lane:status)@nodeNotFound";
 // WARP message received after lane not found
-"@unlinked(node:\"/hotel/room/123\",lane:invalid_lane_name)@laneNotFound"
+"@unlinked(node:\"/hotel/room/123\",lane:invalid_lane_name)@laneNotFound";
 ```
 
 ### Linking and Syncing
@@ -161,21 +175,36 @@ The `synced` method returns `true` if the WARP link is currently synchronized wi
 Take this example of opening a simple `ValueDownlink`. Notice that `syncs` is set to `false` so we see "willLink" logged to output.
 
 ```javascript
-const downlink = client.current.downlinkValue({
-  hostUri: "warp://example.com",
-  nodeUri: "hotel/room/123",
-  laneUri: "status",
-  syncs: true,
-  willLink: () => { console.log("willLink"); },
-  didLink: () => { console.log("didLink"); },
-  willSync: () => { console.log("willSync"); },
-  didSync: () => { console.log("didSync"); },
-  didSet: () => { console.log("didSet"); },
-  didClose: () => { console.log("didClose"); },
-})
-.open();
-
-setTimeout(() => { downlink.close(); }, 1000);
+const downlink = client.current
+  .downlinkValue({
+    hostUri: "warp://example.com",
+    nodeUri: "hotel/room/123",
+    laneUri: "status",
+    syncs: true,
+    willLink: () => {
+      console.log("willLink");
+    },
+    didLink: () => {
+      console.log("didLink");
+    },
+    willSync: () => {
+      console.log("willSync");
+    },
+    didSync: () => {
+      console.log("didSync");
+    },
+    didSet: () => {
+      console.log("didSet");
+    },
+    didClose: () => {
+      console.log("didClose");
+    },
+  })
+  .open();
+
+setTimeout(() => {
+  downlink.close();
+}, 1000);
 
 /* Output:
   willLink
@@ -183,24 +212,39 @@ setTimeout(() => { downlink.close(); }, 1000);
   didClose */
 ```
 
-When `syncs` is set to `true`, "didSync" appears and "willSyncs" replaces "willLink". 
+When `syncs` is set to `true`, "didSync" appears and "willSyncs" replaces "willLink".
 
 ```javascript
-const downlink = client.current.downlinkValue({
-  hostUri: "warp://example.com",
-  nodeUri: "hotel/room/123",
-  laneUri: "status",
-  syncs: true,
-  willLink: () => { console.log("willLink"); },
-  didLink: () => { console.log("didLink"); },
-  willSync: () => { console.log("willSync"); },
-  didSync: () => { console.log("didSync"); },
-  didSet: () => { console.log("didSet"); },
-  didClose: () => { console.log("didClose"); },
-})
-.open();
-
-setTimeout(() => { downlink.close(); }, 1000);
+const downlink = client.current
+  .downlinkValue({
+    hostUri: "warp://example.com",
+    nodeUri: "hotel/room/123",
+    laneUri: "status",
+    syncs: true,
+    willLink: () => {
+      console.log("willLink");
+    },
+    didLink: () => {
+      console.log("didLink");
+    },
+    willSync: () => {
+      console.log("willSync");
+    },
+    didSync: () => {
+      console.log("didSync");
+    },
+    didSet: () => {
+      console.log("didSet");
+    },
+    didClose: () => {
+      console.log("didClose");
+    },
+  })
+  .open();
+
+setTimeout(() => {
+  downlink.close();
+}, 1000);
 
 /* Output:
   willSync
diff --git a/src/_frontend/mapDownlink.md b/src/_frontend/mapDownlink.md
index facc478..a4894a4 100644
--- a/src/_frontend/mapDownlink.md
+++ b/src/_frontend/mapDownlink.md
@@ -9,7 +9,7 @@ redirect_from:
 
 {% include alert.html title='Version Note' text='This documentation describes Swim JS packages v4.0.0-dev-20230923 or later. Users of earlier package versions may experience differences in behavior.' %}
 
-A MapDownlink synchronizes a shared real-time key-value map with with any Web Agent lane backed by a map. In addition to [**map lanes**]({% link _backend/map-lanes.md %}), this includes [**join value lanes**]({% link _backend/join-value-lanes.md %}) and [**join map lanes**]({% link _backend/join-map-lanes.md %}), which are maps where each entry is its own value lane or maps lane, respectively. In addition to the standard Downlink callbacks, MapDownlink supports registering `didUpdate`, and `didRemove` callbacks for observing changes to downlinked map state — whether remote or local. `didUpdate` is invoked when an existing map key is updated or a new key is added. `didRemove` gets called when a map key is removed.
+A MapDownlink synchronizes a shared real-time key-value map with with any Web Agent lane backed by a map. In addition to [**map lanes**]({% link _java_backend/map-lanes.md %}), this includes [**join value lanes**]({% link _java_backend/join-value-lanes.md %}) and [**join map lanes**]({% link _java_backend/join-map-lanes.md %}), which are maps where each entry is its own value lane or maps lane, respectively. In addition to the standard Downlink callbacks, MapDownlink supports registering `didUpdate`, and `didRemove` callbacks for observing changes to downlinked map state — whether remote or local. `didUpdate` is invoked when an existing map key is updated or a new key is added. `didRemove` gets called when a map key is removed.
 
 Create a MapDownlink with a WARP client's `downlinkMap` method.
 
@@ -18,12 +18,13 @@ MapDownlink implements the standard JavaScript Map interface. Use the `get` meth
 ```typescript
 import { WarpClient } from "@swim/client";
 
-const mapDownlink = client.downlinkMap({
-  hostUri: "warp://example.com",
-  nodeUri: "/hotel/lobby",
-  laneUri: "elevators"
-})
-.open();
+const mapDownlink = client
+  .downlinkMap({
+    hostUri: "warp://example.com",
+    nodeUri: "/hotel/lobby",
+    laneUri: "elevators",
+  })
+  .open();
 mapDownlink.get("guest"); // get the locally cached value associated with the key
 mapDownlink.set("service", newElevator); // locally and remotely insert a new entry
 mapDownlink.delete("parking"); // locally and remotely remove an existing entry
@@ -38,10 +39,10 @@ mapDownlink.didUpdate = (key, value) => {
   } else {
     // insert new UI view for key
   }
-}
+};
 mapDownlink.didRemove((key) => {
   // remove UI view for key
-})
+});
 ```
 
 ## State Type Disambiguation
@@ -69,14 +70,15 @@ MapDownlink state may also be given a type annotation. All that is required is f
 import { WarpClient } from "@swim/client";
 import { Form } from "@swim/structure";
 
-const elevators = client.downlinkValue<Record<string, Elevator>>({
-  hostUri: "warp://example.com",
-  nodeUri: "/hotel/lobby",
-  laneUri: "elevators",
-  keyForm: Form.forString(),
-  valueForm: new ElevatorForm(),
-})
-.open();
+const elevators = client
+  .downlinkValue<Record<string, Elevator>>({
+    hostUri: "warp://example.com",
+    nodeUri: "/hotel/lobby",
+    laneUri: "elevators",
+    keyForm: Form.forString(),
+    valueForm: new ElevatorForm(),
+  })
+  .open();
 
 // typed Elevators object
 elevators.get("guest"); // { id: 12345, currentFloor: 1, occupied: false, lastInspection: 1707216815650 }
diff --git a/src/_frontend/warpClient.md b/src/_frontend/warpClient.md
index 3f9f5a1..e47e749 100644
--- a/src/_frontend/warpClient.md
+++ b/src/_frontend/warpClient.md
@@ -9,7 +9,7 @@ redirect_from:
 
 {% include alert.html title='Version Note' text='This documentation describes Swim JS packages v4.0.0-dev-20230923 or later. Users of earlier package versions may experience differences in behavior.' %}
 
-**WarpClient** is the class which behaves as the primary mechanism for handling connection management and link routing. WARP clients transparently multiplex all links to [**Web Agents**]({% link _backend/web-agents.md %}) on a given host over a single WebSocket connection, and automatically manage the network connection to each host, including reconnection and resynchronization after a network failure. Key lifecycle events may also be observed through the registration of callbacks.
+**WarpClient** is the class which behaves as the primary mechanism for handling connection management and link routing. WARP clients transparently multiplex all links to [**Web Agents**]({% link _java_backend/web-agents.md %}) on a given host over a single WebSocket connection, and automatically manage the network connection to each host, including reconnection and resynchronization after a network failure. Key lifecycle events may also be observed through the registration of callbacks.
 
 Besides managing connections and opening links (from here on called [**downlinks**]({% link _frontend/downlinks.md %})) to Web Agents, WARP clients do many other things. They can be used to send arbitrary WARP commands, provide authentication credentials for hosts, and create HostRef, NodeRef, and LaneRef scopes to facilitate downlink management. Additionally, when multiple downlinks are opened to the same lane of the same remote Web Agent, WARP clients seamlessly handle multicast event routing.
 
@@ -35,7 +35,7 @@ const globalClient = WarpClient.global();
 
 A [**downlink**]({% link _frontend/downlinks.md %}) provides a virtual bidirectional stream over which data can be synchronized between the client and a lane of a remote Web Agent. WARP clients transparently multiplex all links to Web Agents on a given host over a single WebSocket connection. A downlink represents one link in this scenario.
 
-`WarpClient` includes three methods that open different kinds of downlinks. The `downlink` method creates an EventDownlink for streaming raw events from any Web Agent lane. The `valueDownlink` method creates a ValueDownlink for synchronizing state with a Web Agent [value lane]({% link _backend/value-lanes.md %}). A ValueDownlink views its state as a @swim/structure [**Value**](/frontend/structures#value) by default, which itself may represent any kind of JavaScript value, be it primitive or composite. `Value`s may be coerced into a strongly-typed value by passing a `Form` to the `valueForm` option.  The `mapDownlink` method creates a MapDownlink. This type of downlink is useful for synchronizing state with any Web Agent lane backed by a map. In addition to [**map lanes**]({% link _backend/map-lanes.md %}), this includes [**join value lanes**]({% link _backend/join-value-lanes.md %}) and [**join map lanes**]({% link _backend/join-map-lanes.md %}), which are maps of other value lanes and maps lanes, respectively.
+`WarpClient` includes three methods that open different kinds of downlinks. The `downlink` method creates an EventDownlink for streaming raw events from any Web Agent lane. The `valueDownlink` method creates a ValueDownlink for synchronizing state with a Web Agent [value lane]({% link _java_backend/value-lanes.md %}). A ValueDownlink views its state as a @swim/structure [**Value**](/frontend/structures#value) by default, which itself may represent any kind of JavaScript value, be it primitive or composite. `Value`s may be coerced into a strongly-typed value by passing a `Form` to the `valueForm` option. The `mapDownlink` method creates a MapDownlink. This type of downlink is useful for synchronizing state with any Web Agent lane backed by a map. In addition to [**map lanes**]({% link _java_backend/map-lanes.md %}), this includes [**join value lanes**]({% link _java_backend/join-value-lanes.md %}) and [**join map lanes**]({% link _java_backend/join-map-lanes.md %}), which are maps of other value lanes and maps lanes, respectively.
 
 Here is an example of opening an EventDownlink. We will go into further detail on all of the downlink types in subsequent sections.
 
@@ -43,12 +43,11 @@ Here is an example of opening an EventDownlink. We will go into further detail o
 import { WarpClient } from "@swim/client";
 
 const client = new WarpClient();
-const downlink = client
-  .downlink({
-    hostUri: "warp://example.com",
-    nodeUri: "/building/1",
-    laneUri: "status"
-  })
+const downlink = client.downlink({
+  hostUri: "warp://example.com",
+  nodeUri: "/building/1",
+  laneUri: "status",
+});
 ```
 
 ## Observing Lifecycle Events
@@ -61,19 +60,19 @@ import { WarpClient } from "@swim/client";
 const client = new WarpClient();
 client.hostDidConnect = (host) => {
   console.log("connected to", host);
-}
+};
 client.hostDidDisconnect = (host) => {
   console.log("disconnected from", host);
-}
+};
 client.hostDidAuthenticate = (session, host) => {
   console.log("authenticated to", host, "with session", session.toLike());
-}
+};
 client.hostDidDeauthenticate = (reason, host) => {
   console.log("deauthenticated from", host, "because", reason.toLike());
-}
+};
 client.hostDidFail = (error, host) => {
   console.log("host", host, "failed because", error);
-}
+};
 ```
 
 ## Authentication
@@ -84,7 +83,7 @@ The `authenticate` method associates a credentials structure with a particular h
 import { WarpClient } from "@swim/client";
 
 const client = new WarpClient();
-client.authenticate("warps://example.com", {"@openId": jwt});
+client.authenticate("warps://example.com", { "@openId": jwt });
 ```
 
 Distinct `WarpClient` instances can be used to create isolated connection pools for different security domains.
@@ -93,10 +92,10 @@ Distinct `WarpClient` instances can be used to create isolated connection pools
 import { WarpClient } from "@swim/client";
 
 const userClient = new WarpClient();
-userClient.authenticate("warps://example.com", {"@openId": userJwt});
+userClient.authenticate("warps://example.com", { "@openId": userJwt });
 
 const toolClient = new WarpClient();
-toolClient.authenticate("warps://example.com", {"@oauth": toolJwt});
+toolClient.authenticate("warps://example.com", { "@oauth": toolJwt });
 ```
 
 ## Sending Commands
@@ -128,11 +127,12 @@ A `HostRef` only needs a `hostUri` to be initialized.
 import { WarpClient } from "@swim/client";
 
 const hostRef = client.hostRef("warp://example.com");
-hostRef.downlink({
-  nodeUri: "house/kitchen",
-  laneUri: "light"
-})
-.open();
+hostRef
+  .downlink({
+    nodeUri: "house/kitchen",
+    laneUri: "light",
+  })
+  .open();
 ```
 
 The `HostRef.nodeRef` and `HostRef.laneRef` instance methods can be used to create further resolved WARP scopes.
diff --git a/src/_frontend/whatIsWarp.md b/src/_frontend/whatIsWarp.md
index 2a9b6a4..130e5dd 100644
--- a/src/_frontend/whatIsWarp.md
+++ b/src/_frontend/whatIsWarp.md
@@ -17,9 +17,8 @@ In recent years, the WebSocket protocol has emerged, enabling us to open streami
 
 ## WARP (Web Agent Remote Protocol)
 
+WARP is a protocol for multiplexing bidirectional streams between large numbers of URIs over a single WebSocket connection. Multiplexed streams within a WARP connection are called **links**. Just as the World Wide Web has hypertext links between Web Pages, WARP enables actively streaming links between [**Web Agents**]({% link _java_backend/web-agents.md %}) and a browser client or another Web Agent. WARP is like pub-sub without the broker, enabling every state of a Web API to be streamed, without interference from billions of queues. Whether you have a UI trying to display the most up-to-date state, or a Web Agent aggregating real-time data from multiple sources into something more meaningful, lighning fast two-way communication through multiple data streams is made possible over a single WebSocket connection with WARP.
 
-WARP is a protocol for multiplexing bidirectional streams between large numbers of URIs over a single WebSocket connection. Multiplexed streams within a WARP connection are called **links**. Just as the World Wide Web has hypertext links between Web Pages, WARP enables actively streaming links between [**Web Agents**]({% link _backend/web-agents.md %}) and a browser client or another Web Agent. WARP is like pub-sub without the broker, enabling every state of a Web API to be streamed, without interference from billions of queues. Whether you have a UI trying to display the most up-to-date state, or a Web Agent aggregating real-time data from multiple sources into something more meaningful, lighning fast two-way communication through multiple data streams is made possible over a single WebSocket connection with WARP.
-
-WARP connections exchange WebSocket frames encoded as [**Recon**]({% link _backend/recon.md %}) structures. The use of Recon enables efficient parsing and routing, while preserving the flexibility and extensibility of protocols like HTTP. And the expressiveness of Recon avoids the explosion of specialized grammars and parsers that has caused the originally simple and elegant HTTP protocol to become bloated and complex. It's also worth noting that, although HTTP/2 introduces a limited form of multiplexing, it multiplexes RPC calls, not full-duplex streams.
+WARP connections exchange WebSocket frames encoded as [**Recon**]({% link _java_backend/recon.md %}) structures. The use of Recon enables efficient parsing and routing, while preserving the flexibility and extensibility of protocols like HTTP. And the expressiveness of Recon avoids the explosion of specialized grammars and parsers that has caused the originally simple and elegant HTTP protocol to become bloated and complex. It's also worth noting that, although HTTP/2 introduces a limited form of multiplexing, it multiplexes RPC calls, not full-duplex streams.
 
 Having a multiplexed streaming protocol allows a large number of links to be made without incurring significant additional overhead. It is an invaluable tool when building UIs which intend to engage in real-time data streaming.
diff --git a/src/_backend/agent-design.md b/src/_java_backend/agent-design.md
similarity index 91%
rename from src/_backend/agent-design.md
rename to src/_java_backend/agent-design.md
index 9706ab8..9c5c867 100644
--- a/src/_backend/agent-design.md
+++ b/src/_java_backend/agent-design.md
@@ -5,7 +5,7 @@ group: Getting Started
 description: "How to model entities into nodes and agents"
 layout: documentation
 redirect_from:
-  - /concepts/agent-design.html
+  - /java/concepts/agent-design.html
 ---
 
 Swim provides a framework to model business entities using distributed objects, the objects being **Web Agents**.
@@ -32,19 +32,18 @@ While nodes and agents are lightweight, they do have some **memory overhead**, t
 **Database comparison**:
 We can draw similarities to relational database design when modelling entities with Swim.
 Table definitions map to web agent definitions, each row in the table being and instance of the web agent.
-Web agent lanes store values and fields so are the columns. 
+Web agent lanes store values and fields so are the columns.
 Finally, the relationships between the tables (foreign keys) can be mirrored using links.
 
 **Examples:**
 
-- **100s of agencies with 1000s of vehicles each**: Create a node for each vehicle (entity agent) which join an agency node (aggregate agent). 
+- **100s of agencies with 1000s of vehicles each**: Create a node for each vehicle (entity agent) which join an agency node (aggregate agent).
 
 - **1000s of users with 1-5 addresses each**: Create a node for each user (entity agent), store the addresses in lanes of the user agents.
-Addresses don't have any behaviour or logic, hence don't need an agent of their own.
+  Addresses don't have any behaviour or logic, hence don't need an agent of their own.
 
 - **100k devices with 100s of sensors each**: Create a node for each device (entity agent), store values of sensors in lanes of the device agents.
-We store the sensors in lanes to avoid creating millions of nodes and therefore a large memory footprint - if each sensor requires modelling explicitly then it may warrant a node per sensor.
-
+  We store the sensors in lanes to avoid creating millions of nodes and therefore a large memory footprint - if each sensor requires modelling explicitly then it may warrant a node per sensor.
 
 ### URIs
 
@@ -69,4 +68,4 @@ This agent could then be added to any node with a longitude and latitude to be r
 
 The Nstream [**patch**](https://www.nstream.io/docs/backend/agent-relationship/) system provides multiple examples of re-usable agents that can be used to compose nodes.
 
-_Note: Keep in mind that as with objects in Java, each agent created will have a small memory overhead._
\ No newline at end of file
+_Note: Keep in mind that as with objects in Java, each agent created will have a small memory overhead._
diff --git a/src/_backend/aggregations.md b/src/_java_backend/aggregations.md
similarity index 92%
rename from src/_backend/aggregations.md
rename to src/_java_backend/aggregations.md
index c859f9a..7a78620 100644
--- a/src/_backend/aggregations.md
+++ b/src/_java_backend/aggregations.md
@@ -6,7 +6,7 @@ cookbook: https://github.com/swimos/cookbook/tree/master/aggregations
 group: Swim Apps
 layout: documentation
 redirect_from:
-  - /guides/aggregations.html
+  - /java/guides/aggregations.html
 ---
 
 It is common to want to group agents together and calculate some aggregate stats across that set of agents.
@@ -14,27 +14,24 @@ It is common to want to group agents together and calculate some aggregate stats
 This pattern can really be extended to any kind of grouping where the members share some property, but some specific examples include:
 
 - Grouping vehicles by city
-  
 - Grouping products by manufacturer
-  
 - Grouping users by role
-  
 - Grouping orders by customer
 
 Throughout this guide, for demonstration, we are going to build out the vehicle example, grouping the vehicles by the state (in the USA) they are currently in.
 
-Let's take a simple vehicle agent as a starting point, the main component of which is a [`ValueLane`]({% link _backend/value-lanes.md %}) that stores the vehicle's status.
+Let's take a simple vehicle agent as a starting point, the main component of which is a [`ValueLane`]({% link _java_backend/value-lanes.md %}) that stores the vehicle's status.
 
 ```java
 public class VehicleAgent extends AbstractAgent {
-    
+
   @SwimLane("addEvent")
   public CommandLane<Value> addEvent = this.<Value>commandLane()
       .onCommand(v -> this.status.set(v));
 
   @SwimLane("status")
   public ValueLane<Value> status = this.<Value>valueLane();
-    
+
 }
 ```
 
@@ -44,27 +41,26 @@ In this example the status of a vehicle is stored as a Swim `Value` but this can
 
 First we are going to construct a simple group/aggregate agent, in our example a `StateAgent`.
 
-A [`JoinValueLane`]({% link _backend/join-value-lanes.md %}) inside the `StateAgent` will become a map, the key being some unique identifier of a vehicle, and the value being the vehicle's current status.
-The lane will keep itself up to date with the `status` of the vehicle through the use of [`downlinks`]({% link _backend/downlinks.md %}).
+A [`JoinValueLane`]({% link _java_backend/join-value-lanes.md %}) inside the `StateAgent` will become a map, the key being some unique identifier of a vehicle, and the value being the vehicle's current status.
+The lane will keep itself up to date with the `status` of the vehicle through the use of [`downlinks`]({% link _java_backend/downlinks.md %}).
 
 ```java
 public class StateAgent extends AbstractAgent {
 
   @SwimLane("vehicles")
   public JoinValueLane<Uri, Value> vehicles = this.<Uri, Value>joinValueLane();
-    
+
 }
 ```
 
 Notice the type parameters of the lane in the above example.
 
 - The first parameter is the type of the unique identifier of the vehicle.
-As a node URI is unique to each agent we will be using that (but this could be anything else unique to the vehicle, e.g. `id: String`).
-  
+  As a node URI is unique to each agent we will be using that (but this could be anything else unique to the vehicle, e.g. `id: String`).
 - The second parameter is the type of the value to be downlinked, this should match the type of the `status` `ValueLane` in the vehicle agent.
 
 Now we need some way for a vehicle to register itself with the state and join the lane.
-To do this we open a [`CommandLane`]({% link _backend/command-lanes.md %}) named `addVehicle` accepting a `Uri` - which will be the vehicle's node URI.
+To do this we open a [`CommandLane`]({% link _java_backend/command-lanes.md %}) named `addVehicle` accepting a `Uri` - which will be the vehicle's node URI.
 The `downlink(K key)` method on the join value lane creates a downlink with the given unique key.
 We also specify the `nodeUri` and `laneUri` then start the downlink with `open()`.
 
@@ -100,14 +96,13 @@ The method will accept a state's name and then command the state's `addVehicle`
   }
 ```
 
-_Note: We have to convert the vehicle's node URI to a `Value` to send it via a command. For more information on this see [Forms]({% link _backend/forms.md %})._
+_Note: We have to convert the vehicle's node URI to a `Value` to send it via a command. For more information on this see [Forms]({% link _java_backend/forms.md %})._
 
 We now need to call the above method, exactly when you will want to do this will depend on the use case.
 The most common cases are:
 
 - **Agent Start**: Call within the agent's `didStart()` lifecycle callback to join immediately on agent start.
-The value ('state' in this example) can be static or loaded from a property of some kind.
-  
+  The value ('state' in this example) can be static or loaded from a property of some kind.
 - **On Event**: Call from a lane's callback functions, this will allow the agent to join the group agent when some condition is met.
 
 Both approaches have a similar implementation, but we will show both.
@@ -257,14 +252,14 @@ For any other count, for example, a count of vehicles currently moving, we can l
 
 ```java
   private void computeStatus() {
-    
+
     int movingVehicles = 0;
     for (final Uri vehicleUri : this.vehicles.keySet()) {
       if (this.vehicles.get(vehicleUri).get("isMoving").booleanValue(false)) {
         movingVehicles++;
       }
     }
-    
+
     this.status.set(
         Record.create(2)
             .slot("vehicle_count", this.vehicles.size())
@@ -281,10 +276,10 @@ Calculating a mean is done by looping through all the entries of the join value
   private void computeStatus() {
 
     int totalSpeed = 0, movingVehicles = 0;
-    
+
     for (final Uri vehicleUri : this.vehicles.keySet()) {
       totalSpeed += this.vehicles.get(vehicleUri).get("speed").intValue(0);
-      
+
       if (this.vehicles.get(vehicleUri).get("isMoving").booleanValue(false)) {
         movingVehicles++;
       }
diff --git a/src/_backend/auth-policy.md b/src/_java_backend/auth-policy.md
similarity index 91%
rename from src/_backend/auth-policy.md
rename to src/_java_backend/auth-policy.md
index ea775a1..693f91c 100644
--- a/src/_backend/auth-policy.md
+++ b/src/_java_backend/auth-policy.md
@@ -6,11 +6,11 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/auth_policy
 redirect_from:
-  - /reference/auth-policy.html
-  - /tutorials/auth-policy/
+  - /java/reference/auth-policy.html
+  - /java/tutorials/auth-policy/
 ---
 
-In the [Planes guide]({% link _backend/planes.md %}), we created a security policy to only allow requests with a given token URL parameter. This guide will expand upon this to show how access can be restriced for given Agents and Lanes.
+In the [Planes guide]({% link _java_backend/planes.md %}), we created a security policy to only allow requests with a given token URL parameter. This guide will expand upon this to show how access can be restriced for given Agents and Lanes.
 
 ### Declaration and Instantiation
 
diff --git a/src/_backend/cli.md b/src/_java_backend/cli.md
similarity index 94%
rename from src/_backend/cli.md
rename to src/_java_backend/cli.md
index 89d2111..d7786ad 100644
--- a/src/_backend/cli.md
+++ b/src/_java_backend/cli.md
@@ -5,7 +5,7 @@ description: "How to stream or fetch data from a Swim application using the swim
 group: Utilities
 layout: documentation
 redirect_from:
-  - /guides/cli.html
+  - /java/guides/cli.html
 ---
 
 The [**swim-cli**](https://www.npmjs.com/package/@swim/cli) is the simplest way to fetch or stream data from a Swim application.
@@ -47,7 +47,7 @@ swim-cli link -h warps://cellular.swim.services -n /country/US/state/CA -l statu
 swim-cli sync -h warps://cellular.swim.services -n /country/US/state/CA -l status
 ```
 
-These commands will both stream any updates to the `status` lane of the `/country/US/state/CA` node, however **sync** first gets the current value of the lane. 
+These commands will both stream any updates to the `status` lane of the `/country/US/state/CA` node, however **sync** first gets the current value of the lane.
 (Try them yourself)
 
 _Note: The difference between sync and link becomes more obvious when streaming a map lane - see next section._
@@ -63,7 +63,7 @@ Example output from **value** lane:
 {siteCount:1193,warnCount:115,alertCount:10}
 ```
 
-When streaming a **map** lane,  we only send the new value of the entry that has been updated.
+When streaming a **map** lane, we only send the new value of the entry that has been updated.
 This means the output of the stream must now include the key of the entry being updated (or removed).
 We can stream a **map** lane (`alerts`) as an example:
 
@@ -96,18 +96,18 @@ Notice the `-h`, `-n`, `-l` options are for the URI of `host`, `node`, and `lane
 swim-cli get -h warps://cellular.swim.services -n /country/US/state/CA -l status
 ```
 
-This will return the current value of the `status` lane of the `/country/US/state/CA` node. 
+This will return the current value of the `status` lane of the `/country/US/state/CA` node.
 (Try it yourself)
 
 The **get** command terminates after fetching the current value.
 
 ### Formatting Output (JSON)
 
-All of the above commands by default return output in a **recon** format. 
+All of the above commands by default return output in a **recon** format.
 The `-f` option can be used to specify you would like to receive the output in a **json**.
 
 ```bash
 swim-cli link -h warps://cellular.swim.services -n /country/US/state/CA -l status -f json
 ```
 
-(Try it yourself)
\ No newline at end of file
+(Try it yourself)
diff --git a/src/_java_backend/command-lanes.md b/src/_java_backend/command-lanes.md
new file mode 100644
index 0000000..ea5053b
--- /dev/null
+++ b/src/_java_backend/command-lanes.md
@@ -0,0 +1,221 @@
+---
+title: Command Lanes
+short-title: Command Lanes
+description: "Remotely command Web Agents to take action, and observe the actions taken by others."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/command_lanes
+redirect_from:
+  - /java/tutorials/command-lanes/
+  - /java/reference/command-lanes.html
+---
+
+In the [Web Agents guide]({% link _java_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+
+Lanes come in many flavors, but every lane type exposes:
+
+- A **means to act** on this lane
+- Customizable **lifecycle callbacks** that execute during the runtime of this action
+- Various means to **strongly type** (i.e. **parametrize**) the lane
+- Universal WARP **subscriptions** to this lane
+
+A **command lane** is the simplest type of lane, that meets the following requirements:
+
+- Every command lane can be **commanded** with a message
+- Doing so will trigger its **onCommand()** lifecycle callback
+- The parameter on a command lane indicates the type of the message with which it is commanded
+- Even though command lanes do not directly store any values, their updates can still be subscribed to via an **event downlink**
+
+## Declaration
+
+All lanes are declared inside Web Agents as fields annotated with `@SwimLane`. The parameter inside this annotation is the lane's **laneUri**. Recall that every Web Agent has a universal, logical address known as its **nodeUri**; laneUris are simply the equivalent counterparts for lanes.
+
+The following declaration is sufficient to make the `publish` lane of every `UnitAgent` addressable by the laneUri `"publish"`:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("publish")
+  CommandLane<Integer>; publish;
+}
+```
+
+Internally, lanes are always backed by `swim.structure.Value`s, regardless of their parametrized types. Under the hood, lanes use **forms** to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types provided that a form for that data type exists. Even custom Java classes can be lane types, provided that forms for those classes exist. We will further discuss this topic in a more advanced cookbook.
+
+<!--Further reading: <a href="/reference/universal-addressability">Universal Addressability</a>, <a href="/reference/structures">Structures</a>
+-->
+
+### Instantiation and `onCommand()`
+
+The `AbstractAgent` class comes with utility methods to construct lanes and make them accessible by the Swim runtime. Recall, however, that developers rarely instantiate Web Agents by explicitly invoking their constructors. The recommended pattern for adding a command lane to an Agent is to:
+
+- Exclude constructors entirely from Web Agents
+- Use the `commandLane()` method to instantiate the lane; note that this is a parametrized method
+- Through a builder pattern, override the lane's `void onCommand(V value)` method
+
+This **onCommand()** lifecycle callback is executed every time its lane is commanded with some value, and it has access to the value with which it was commanded.
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.recon.Recon;
+import swim.structure.Value;
+
+public class UnitAgent extends AbstractAgent {
+
+  @SwimLane("publish")
+  CommandLane<Integer> publish = this.<Integer>commandLane()
+      .onCommand((Integer msg) -> {
+        logMessage("'publish' commanded with " + msg);
+      });
+
+  @SwimLane("publishValue")
+  CommandLane<Value> publishV = this.<Value>commandLane()
+      .onCommand((Value msg) -> {
+        logMessage("'publishValue' commanded with " + Recon.toString(msg));
+      });
+
+  private void logMessage(Object msg) {
+    System.out.println(nodeUri() + ": " + msg);
+  }
+}
+```
+
+### External Addressability and `command()`
+
+Lanes are Swim server endpoints; therefore, external processes must be able to access them directly. Just like accessing the `foo` field of an object `obj` in object-oriented paradigms requires both `obj` and `foo` in some way (e.g. `obj.foo`), addressing a lane requires both its laneUri and the nodeUri of its enclosing agent. Additionally, if the request comes from a different Swim runtime from where the target lane lives (i.e. an entirely different plane or a Swim client instance), then the request must also identify the **hostUri** on which the Swim server is running.
+
+To demonstrate, let's modify the behavior of our `"publish"` lane to itself relay commands to `"publishValue"`:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.recon.Recon;
+import swim.structure.Record;
+import swim.structure.Value;
+import swim.uri.Uri;
+
+public class UnitAgent extends AbstractAgent {
+
+  @SwimLane("publish")
+  CommandLane<Integer> publish = this.<Integer>commandLane()
+      .onCommand((Integer msg) -> {
+        logMessage("`publish` commanded with " + msg);
+        final Value updatedMsg = Record.create(1).slot("fromServer", msg);
+        // command() "updatedMsg" TO
+        // the "publishValue" lane OF
+        // the agent addressable by "nodeUri()" RUNNING ON
+        // this plane (indicated by no hostUri argument)
+        command(nodeUri(), Uri.parse(&quotpublishValue&quot), updatedMsg);
+      });
+
+  @SwimLane("publishValue")
+  CommandLane<Value> publishV = this.<Value>commandLane()
+      .onCommand((Value msg) -> {
+        logMessage("'publishValue' commanded with " + Recon.toString(msg));
+      });
+
+  private void logMessage(Object msg) {
+    System.out.println(nodeUri() + ": " + msg);
+  }
+}
+```
+
+And, in a separate process, command `"publish"` from a different Swim handle (a Swim client is easiest):
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.client.ClientRuntime;
+import swim.structure.Num;
+import swim.structure.Value;
+
+class CustomClient {
+  public static void main(String[] args) throws InterruptedException {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+    final Value msg = Num.from(9035768);
+    // command "msg" TO
+    // the "publish" lane OF
+    // the agent addressable by "/unit/master" RUNNING ON
+    // the plane with hostUri "warp://localhost:9001"
+    swimClient.command("warp://localhost:9001", "/unit/master", "publish", msg);
+
+    System.out.println("Will shut down client in 2 seconds");
+    Thread.sleep(2000);
+    swimClient.stop();
+  }
+}
+```
+
+{% include alert.html title='Caution' text='If you have multiple lanes within an Agent type, ensure that their laneUris are not identical. Suppose we declare two different command lanes within our <strong>UnitAgent</strong> with laneUri <strong>"takeAction"</strong>; how would the Swim runtime know which one to message? That said, reusing laneUris <strong>across</strong> Agent types is perfectly acceptable, as requests corresponding to these are guaranteed to have different nodeUris.' %}
+
+Note that the `command()` signature only allows for `swim.structure.Value` payloads. Lanes internally use _forms_ to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types, provided that a form for that data type exists. Even a custom Java class can be a lane type, provided that a form for that class exists. We will further discuss this topic in a more advanced cookbook.
+
+<!--Further reading: <a href="/reference/universal-addressability">Universal Addressability</a>, <a href="/reference/planes">Planes</a> <a href="/reference/structures">Structures</a>
+-->
+
+### Subscription
+
+Downlinks are WARP subscriptions to lanes. They come in many flavors, but subscriptions to command lanes can only be achieved via **event downlinks**.
+
+Downlinks can be instantiated within any Swim handle. Just like command messages, the desired hostUri (unless the lane is within the same Swim handle), nodeUri, and laneUri must be identified in advance. Let's enhance `CustomClient` logic to watch the effects of our command messages:
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.api.downlink.EventDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Num;
+import swim.structure.Value;
+
+class CustomClient {
+  public static void main(String[] args) throws InterruptedException {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+
+    final String hostUri = "warp://localhost:9001";
+    final String nodeUri = "/unit/master";
+    swimClient.command(hostUri, nodeUri, "WAKEUP", Value.absent());
+
+    final EventDownlink<Value> link = swimClient.downlink()
+        .hostUri(hostUri).nodeUri(nodeUri).laneUri("publishValue")
+        .onEvent(event -> {
+          System.out.println("link received event: " + event);
+        })
+        .open();
+    final Value msg = Num.from(9035768);
+    // command() "msg" TO
+    // the "publish" lane OF
+    // the agent addressable by "/unit/master" RUNNING ON
+    // the plane with hostUri "warp://localhost:9001"
+    swimClient.command(hostUri, nodeUri, "publish", msg);
+
+    System.out.println("Will shut down client in 2 seconds");
+    Thread.sleep(2000);
+    swimClient.stop();
+  }
+}
+```
+
+Further reading: [Downlinks]({% link _java_backend/downlinks.md %})
+
+## Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/command_lanes).
diff --git a/src/_backend/demand-map-lanes.md b/src/_java_backend/demand-map-lanes.md
similarity index 93%
rename from src/_backend/demand-map-lanes.md
rename to src/_java_backend/demand-map-lanes.md
index 3683b93..80ed914 100644
--- a/src/_backend/demand-map-lanes.md
+++ b/src/_java_backend/demand-map-lanes.md
@@ -6,20 +6,20 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/demand_map_lanes
 redirect_from:
-  - /tutorials/demand-map-lanes/
-  - /reference/demand-map-lanes.html
+  - /java/tutorials/demand-map-lanes/
+  - /java/reference/demand-map-lanes.html
 ---
 
-In the [Web Agents guide]({% link _backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+In the [Web Agents guide]({% link _java_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
 
 Lanes come in many flavors, but every lane type exposes:
 
 - A **means to act** on this lane
 - Customizable **lifecycle callbacks** that execute during the runtime of this action
-- Various means to **strongly type** (i.e. *parametrize*) the lane
+- Various means to **strongly type** (i.e. _parametrize_) the lane
 - Universal WARP **subscriptions** to this lane
 
-A **demand map lane** does not store a collection, instead they are backed by a [map lane]({% link _backend/map-lanes.md %}) and retrieve values purely on demand. Demand map lanes **lazily** generate events for the map lane, only when there is an uplink ready to receive the event. The lane meets these requirements:
+A **demand map lane** does not store a collection, instead they are backed by a [map lane]({% link _java_backend/map-lanes.md %}) and retrieve values purely on demand. Demand map lanes **lazily** generate events for the map lane, only when there is an uplink ready to receive the event. The lane meets these requirements:
 
 - Every demand map lane can be **cue(key)**-ed, signalling there is an event to be sent, for given key, to the uplinks, if ready. This is done in the map lane's `didUpdate()` method
 - Doing so will trigger its **onCue(key)** callback
@@ -192,11 +192,11 @@ protected DemandMapLane<String, String> data = this.<String, String>demandMapLan
     })
     .onSync(uplink -> {
         final String name = uplink.laneUri().query().get("name");
-        return (this.raw.containsKey(name)) ? 
+        return (this.raw.containsKey(name)) ?
             Collections.singletonList(name).iterator() : Collections.emptyIterator();
     });
 ```
 
 ### Try It Yourself
-  
+
 A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/demand_map_lanes).
diff --git a/src/_backend/demand-value-lanes.md b/src/_java_backend/demand-value-lanes.md
similarity index 90%
rename from src/_backend/demand-value-lanes.md
rename to src/_java_backend/demand-value-lanes.md
index 1d3e1ee..4198757 100644
--- a/src/_backend/demand-value-lanes.md
+++ b/src/_java_backend/demand-value-lanes.md
@@ -6,20 +6,20 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/demand_value_lanes
 redirect_from:
-  - /tutorials/demand-value-lanes/
-  - /reference/demand-value-lanes.html
+  - /java/tutorials/demand-value-lanes/
+  - /java/reference/demand-value-lanes.html
 ---
 
-In the [Web Agents guide]({% link _backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+In the [Web Agents guide]({% link _java_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
 
 Lanes come in many flavors, but every lane type exposes:
 
 - A **means to act** on this lane
 - Customizable **lifecycle callbacks** that execute during the runtime of this action
-- Various means to **strongly type** (i.e. *parametrize*) the lane
+- Various means to **strongly type** (i.e. _parametrize_) the lane
 - Universal WARP **subscriptions** to this lane
 
-A **demand lane** does not store any value, instead they are backed by a [value lane]({% link _backend/value-lanes.md %}) and retrieve values purely on demand. Demand lanes **lazily** generate events for the value lane, only when there is an uplink ready to receive the event. The lane meets these requirements: 
+A **demand lane** does not store any value, instead they are backed by a [value lane]({% link _java_backend/value-lanes.md %}) and retrieve values purely on demand. Demand lanes **lazily** generate events for the value lane, only when there is an uplink ready to receive the event. The lane meets these requirements:
 
 - Every demand lane can be **cue**-ed, signalling there is an event to be sent to the uplinks, if ready. This is done in the value lane's `didSet()` method
 - Doing so will trigger its **onCue()** callback
@@ -44,7 +44,7 @@ import swim.api.SwimLane;
 import swim.api.agent.AbstractAgent;
 import swim.api.lane.DemandLane;
 
-public class UnitAgent extends AbstractAgent { 
+public class UnitAgent extends AbstractAgent {
   @SwimLane("data")
   DemandLane<String> data;
 }
@@ -123,7 +123,7 @@ There are two ways to read data from demand lanes, both of which require opening
 
 The simpler approach is to simply call `get()` on the downlink to read its value at the time of the invocation.
 
-The far more powerful approach uses the fact that value downlinks *also* have access to `didSet()`. This enables an event-driven style of programming where client programs are treated as completely in sync with the server. And, excluding network latency and backpressure regulation of network packets, they basically are.
+The far more powerful approach uses the fact that value downlinks _also_ have access to `didSet()`. This enables an event-driven style of programming where client programs are treated as completely in sync with the server. And, excluding network latency and backpressure regulation of network packets, they basically are.
 
 The following is an example of how the Swim client would create a downlink to the `data` demand lane we created in the previous code snippet:
 
@@ -157,4 +157,3 @@ public class CustomClient {
 ### Try It Yourself
 
 A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/demand_value_lanes).
-
diff --git a/src/_backend/downlinks.md b/src/_java_backend/downlinks.md
similarity index 93%
rename from src/_backend/downlinks.md
rename to src/_java_backend/downlinks.md
index f7fbcc3..080f2f2 100644
--- a/src/_backend/downlinks.md
+++ b/src/_java_backend/downlinks.md
@@ -6,11 +6,11 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/downlinks
 redirect_from:
-  - /tutorials/downlinks/
-  - /reference/downlinks.html
+  - /java/tutorials/downlinks/
+  - /java/reference/downlinks.html
 ---
 
-In the [Web Agents guide]({% link _backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects** and **lanes** are **fields**. **Downlinks** are bidirectionally-streaming, persistent **subscriptions** to lanes.
+In the [Web Agents guide]({% link _java_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects** and **lanes** are **fields**. **Downlinks** are bidirectionally-streaming, persistent **subscriptions** to lanes.
 
 Downlinks come in many flavors, but there are only two broad downlink categories. An **event downlink** can subscribe to any lane and provides:
 
@@ -89,7 +89,7 @@ class CustomClient {
 }
 ```
 
-Server-side, downlinks are explained in the [Server Downlinks guide]({% link _backend/server-downlinks.md %}).
+Server-side, downlinks are explained in the [Server Downlinks guide]({% link _java_backend/server-downlinks.md %}).
 
 ### JavaScript
 
@@ -100,4 +100,3 @@ Furthermore, the tutorial application demonstrates [using value downlinks](https
 ### Try It Yourself
 
 A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/downlinks).
-
diff --git a/src/_backend/egress-bridges.md b/src/_java_backend/egress-bridges.md
similarity index 98%
rename from src/_backend/egress-bridges.md
rename to src/_java_backend/egress-bridges.md
index 30a683b..ebf09e9 100644
--- a/src/_backend/egress-bridges.md
+++ b/src/_java_backend/egress-bridges.md
@@ -6,8 +6,8 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/egress_bridges
 redirect_from:
-  - /tutorials/egress-bridges/
-  - /reference/egress-bridges.html
+  - /java/tutorials/egress-bridges/
+  - /java/reference/egress-bridges.html
 ---
 
 Swim's built-in networking stack enables communication with other processes--which might themselves be other Swim servers. There are two directions of data flow: from Swim to external processes, and from external processes to Swim. This article discusses the former.
diff --git a/src/_backend/flink-connector.md b/src/_java_backend/flink-connector.md
similarity index 96%
rename from src/_backend/flink-connector.md
rename to src/_java_backend/flink-connector.md
index fb9194d..6f049c1 100644
--- a/src/_backend/flink-connector.md
+++ b/src/_java_backend/flink-connector.md
@@ -5,7 +5,7 @@ description: "Use the Flink Swim Sink to stream events to a Swim application."
 group: Data Ingestion
 layout: documentation
 redirect_from:
-  - /guides/flink-connector.html
+  - /java/guides/flink-connector.html
 ---
 
 Swim provides a Flink connector for writing data from Flink jobs to Swim servers.
@@ -35,7 +35,7 @@ The destination Swim endpoint, consisting of `hostUri`, `nodeUri` and `laneUri`,
 These methods accept a `String` or a function mapping the source data type to a `String`.
 
 The other mandatory field, the `RecordValueMolder`, defines a method of casting the source data type to a Swim `Value` type.
-Swim `Form` provides a general method for molding an object into a `Value`, as above, but structure of messages can be customized (see [Forms]({% link _backend/forms.md %})).
+Swim `Form` provides a general method for molding an object into a `Value`, as above, but structure of messages can be customized (see [Forms]({% link _java_backend/forms.md %})).
 
 ### Local Example
 
@@ -62,14 +62,14 @@ public class SwimSinkExampleFlinkJob {
 
     env.execute();
   }
-  
+
   static class User {
-    
+
     final int id;
     final double longitude;
     final double latitude;
     final double score;
-    
+
     public User(int id, double longitude, double latitude, double score) {
       this.id = id;
       this.longitude = longitude;
@@ -78,4 +78,4 @@ public class SwimSinkExampleFlinkJob {
     }
   }
 }
-```
\ No newline at end of file
+```
diff --git a/src/_backend/forms.md b/src/_java_backend/forms.md
similarity index 98%
rename from src/_backend/forms.md
rename to src/_java_backend/forms.md
index e861906..22cb307 100644
--- a/src/_backend/forms.md
+++ b/src/_java_backend/forms.md
@@ -6,8 +6,8 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/forms
 redirect_from:
-  - /tutorials/forms/
-  - /reference/forms.html
+  - /java/tutorials/forms/
+  - /java/reference/forms.html
 ---
 
 Recall that internally, as in all previous "... Lanes" cookbooks to date, `swim.structure.Value` is the type of every lane, regardless of its parametrized type.
@@ -25,7 +25,7 @@ An instance of `swim.structure.Form<T>` handles transformations between `Value`
 When declaring a lane parametrized with a type `T`, the Swim core **always** uses some `Form<T>` to manage conversions under the hood.
 
 Several methods implemented in the `BarType` class handle these transformations manually.
-  
+
 #### Types of Forms
 
 The `swim.structure.form` package contains many out-of-the-box Forms already for a variety of common [types](https://github.com/swimos/swim/tree/main/swim-java/swim-runtime/swim-core/swim.structure/src/main/java/swim/structure/form), such as LongForm, CharacterForm, and StringForm. This is why one can declare, for example, a `MapLane<String, Long>` that works without any additional effort.
@@ -37,7 +37,7 @@ There are two methods to achieve this: the "no-magic" (explicit) way exercised i
 #### The BarType Class
 
 There are several methods responsible for handling transformations between `Value` types and a custom Java object such as `BarType`:
-  
+
 ##### **- mold()**
 
 The `mold()` method is used to convert the fields of some custom object into a Swim structure of type `Value`.
@@ -53,7 +53,7 @@ public Value mold(BarType barType) {
     .slot("j", barType.getNumber2());
 }
 ```
-    
+
 ##### **- cast()**
 
 The `cast()` method is responsible for the inverse operation, parsing a `Value` into a Java object of the class type, e.g. `BarType`
@@ -77,7 +77,7 @@ public BarType cast(Item value) {
   }
 }
 ```
-        
+
 ##### **- tag()**
 
 By default, the `Attr` associated with a Form, such as that in `Record.create(3).attr("fooType").slot("i", 5).slot("s", "potato");`, defaults to a camelCase string of the class name. The `tag()` method can be used to explicitly set a unique id for objects of a pojo.
@@ -91,7 +91,7 @@ class BarTypeForm extends Form<BarType> {
   }
 }
 ```
-   
+
 ##### **- type()**
 
 The `type()` method is used to return the type of an object in the form of its defined class.
@@ -102,11 +102,11 @@ public Class<?> type() {
     return BarType.class;
 }
 ```
- 
+
 #### The FooType Class
 
 The FooType class in this project sets out a method of streamlining the process of defining a custom Form through more succinct annotations.
-  
+
 ##### **- @Kind**
 
 The `@Kind` annotation is used to tag a static accessor method for a custom Form.
@@ -116,7 +116,7 @@ The `@Kind` annotation is used to tag a static accessor method for a custom Form
 @Kind
 private static Form<FooType> form;
 ```
-  
+
 ##### **- @Tag**
 
 A shorthand way of overriding the default classname `Attr` picked up by the reflection api.
@@ -125,7 +125,7 @@ A shorthand way of overriding the default classname `Attr` picked up by the refl
 // swim/basic/FooType.java
 @Tag("fooType")
 ```
-  
+
 ##### **- @Member**
 
 By default, the variable name of a class member will get picked up as the default attribute. However, as in `@Tag`, this string can be overriden using the `@Member` annotation.
@@ -157,7 +157,7 @@ public static Form<FooType> form() {
     return form;
 }
 ```
-    
+
 ### Advanced Topic: Composability
 
 Consider the problem of creating Forms for some type `TrickyType`, whose fields are other pojos that each have their own Forms.
@@ -179,9 +179,8 @@ public class BazType {
   ...
 }
 ```
-  
-This clean composability also enables some of the more complicated forms that were [linked](https://github.com/swimos/swim/tree/main/swim-java/swim-runtime/swim-core/swim.structure/src/main/java/swim/structure/form) earlier. For example, one can get a working `Form<List<FooType>` handle by simply doing `Form<List<FooType> = Form.forList(FooType.form())` (see [here](https://github.com/swimos/swim/blob/main/swim-java/swim-runtime/swim-core/swim.structure/src/main/java/swim/structure/Form.java#L221-L246){:data-proofer-ignore=''}). Even something like a `Form<List<List<BazType>` could be created similarly!
 
+This clean composability also enables some of the more complicated forms that were [linked](https://github.com/swimos/swim/tree/main/swim-java/swim-runtime/swim-core/swim.structure/src/main/java/swim/structure/form) earlier. For example, one can get a working `Form<List<FooType>` handle by simply doing `Form<List<FooType> = Form.forList(FooType.form())` (see [here](https://github.com/swimos/swim/blob/main/swim-java/swim-runtime/swim-core/swim.structure/src/main/java/swim/structure/Form.java#L221-L246){:data-proofer-ignore=''}). Even something like a `Form<List<List<BazType>` could be created similarly!
 
 ### Try It Yourself
 
diff --git a/src/_java_backend/fundamentals.md b/src/_java_backend/fundamentals.md
new file mode 100644
index 0000000..88a9f7d
--- /dev/null
+++ b/src/_java_backend/fundamentals.md
@@ -0,0 +1,70 @@
+---
+title: SwimOS Fundamentals
+short-title: SwimOS Fundamentals
+description: "Learn about SwimOS fundamentals and concepts."
+group: Getting Started
+layout: documentation
+redirect_from:
+  - /java/fundamentals/
+  - /java/concepts/fundamentals.html
+---
+
+Streaming Data Applications are an emerging architectural approach that affords application functionality to streaming data. The three foundational components of Streaming Data Applications are:
+
+- Stateful Objects
+- Streaming APIs
+- Real-Time UIs
+
+## Stateful Objects
+
+A Stateful Object is a simple object representation of a business entity that lives amongst your streaming data. It is very much like a Plain Old Java Object (POJO) equipped with some additional superpowers. A Stateful Object continuously consumes updates of synced state. For each update, it computes new state that automatically gets synced to listeners without explicit action or coordination.
+
+SwimOS’s implementation of Stateful Objects are called Web Agents. They are web-addressable, distributed objects for business entities. Like a traditional object, they marry state with behavior. Instead of requests and queries, Web Agents subscribe to updates or have them pushed directly during ingestion whenever information for the underlying entity comes in. Web Agents subscribe to all the state needed to take action for its corresponding entity. We call this full-context business logic because it takes in first-order entity state, as well as the first-order states of requisite entities, and then the second-order state generated by stream processing, and finally, all applicable derived state from other Web Agents.
+
+## Streaming APIs
+
+With polling, load scales with how often you ask. With streaming, load scales with how often data changes. True real-time is impossible with polling because you would have to poll infinitely fast. E-Tag caching has provide a big improvement, but cannot achieve the degree of low-latency compared to streaming.
+
+Streaming APIs move data the moment it is available and keep it moving until the data has been sent to all subscribers. Producers are decoupled from consumers because the Streaming API implementation handles the routing and hopefully enforcing access controls. Using efficient routing, a stream’s journey can satisfy multiple subscribers along the way achieving efficiency gains. Rigid point-to-point methods preclude such gains.
+
+With an optimal, massively scalable Streaming API implementation like that of SwimOS, the Streaming API will use multiplexing to batch potentially massive concurrent updates into a single stream.
+
+Additionally, while events are compact, they are verbose compared to differential state sync methods. A recurring event may require zero update to an entity's state based on business logic, or it might require advancing or flipping a bit or two, or anywhere less than the event’s payload. This is because business logic can determine the impact on state by executing its own very specific business logic. Furthermore, this underscores a point that can be easy to miss, when a system syndicates events, every recipient has upon itself the requirement to process that event. An event routinely reaching 100s or 1000s or more recipients within the network will dramatically compound the toll of event processing in the system. On the other hand, if the system impels execution of business logic and only transmits the resulting state change deltas, rather than compounding the toll of event processing, the beneficial derived state that results from event processing is advantageously compounded instead. For this reason, SwimOS uses differential state sync as opposed to simple event propagation for its Streaming API implementation.
+
+On top of the dramatic scalability increases by orders of magnitude, a Streaming API will impart performance and efficiency gains outside of the processing network by exposing web-friendly, streaming APIs to web-enabled endpoints. As a result, though User Interfaces may be outside the network, they will no longer be left outside the real-time delivery pipeline. Now, with Streaming APIs, end-to-end, uninterrupted streaming at half-ping latency can fulfill the real-time imperative mandated by these historically underserved clients in the first place.
+
+## Real-Time UIs
+
+Traditional UIs play out like a power point presentation or time lapsed photography video. A Real-Time UI offers the 60-frame-per-second experience, constantly but judiciously updating. Nstream’s Real-time UIs are designed for scalable real-time streaming, ensuring that the browser doesn’t get overwhelmed and that the most appropriate data is prioritized with respect to what is in view and the desired level of detail.
+
+Simply connecting the browser to an array of web sockets is a recipe for disaster when the volume of data is too large and too fast. Beneath web-developer friendly typescript APIs, SwimOS’s Real-Time UI library includes battle-tested real-time data processing components that have proven themselves at massive scale with large enterprise customers.
+
+## SwimOS Concepts
+
+Swim unifies the traditionally disparate roles of database, message broker, job manager, and application server, into a few simple constructs: **Web Agents**, **Lanes**, **Links**, **Recon**, and **WARP**.
+
+<div class="h-screen">
+  <img src="{{ '/assets/images/agents-lanes-links.svg' | absolute_url }}" class="mx-auto" alt="Agents, lanes, and links">
+</div>
+
+### Web Agents
+
+Swim applications consist of interconnected, distributed objects, called [Web Agents]({% link _java_backend/web-agents.md %}). Each Web Agent has URI address, like a REST endpoint. But unlike RESTful Web Services, Web Agents are stateful, and accessed via streaming APIs.
+
+### Lanes
+
+If Web Agents are distributed objects, then [lanes]({% link _java_backend/lanes.md %}) serve as the properties and methods of those objects. Lanes come in many flavors: **value lanes**, **map lanes**, **command lanes**, and **join lanes**, to name a few. Many lanes are internally persistent, acting like encapsulated database tables.
+
+### Links
+
+Distributed objects need a way to communicate. [Links]({% link _java_backend/links.md %}) establishes active references to lanes of Web Agents, transparently streaming bidirectional state changes to keep all parts of an application in sync, without the overhead of queries or remote procedure calls.
+
+### Recon
+
+Communication only works if all parties understand each other. Swim natively speaks a universal, structured data language, called [Recon]({% link _java_backend/recon.md %}). A superset of JSON, XML, Protocol Buffers, and more, Recon naturally translates into many languages. Declare, definine, and utilize Web Agents and their properties using these configuration files.
+
+### WARP
+
+The [Web Agent Remote Protocol (WARP)]({% link _java_backend/warp.md %}) enables bidirectional links to streaming API endpoints, called lanes, of URI-addressed distributed objects, called nodes, that run Web Agents.
+
+Continue reading to learn more about [Web Agents]({% link _java_backend/web-agents.md %}), [Lanes]({% link _java_backend/lanes.md %}), [Links]({% link _java_backend/links.md %}), and [Recon]({% link _java_backend/recon.md %}). Or dive into the [tutorials]({% link _java_tutorials/index.md %}) to learn by doing.
diff --git a/src/_backend/http-ingestion.md b/src/_java_backend/http-ingestion.md
similarity index 98%
rename from src/_backend/http-ingestion.md
rename to src/_java_backend/http-ingestion.md
index a8504f6..3f9b66b 100644
--- a/src/_backend/http-ingestion.md
+++ b/src/_java_backend/http-ingestion.md
@@ -6,7 +6,7 @@ group: Data Ingestion
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/http_ingestion
 redirect_from:
-  - /guides/http-ingestion.html
+  - /java/guides/http-ingestion.html
 ---
 
 This guide illustrates how to develop a Swim application that ingests data from HTTP/REST APIs and instantiates logic-performing Web Agents.
@@ -120,7 +120,7 @@ public final class NextBusApi {
 ### Step 2: `AgencyAgent` Implementation
 
 Because the NextBus endpoint is a REST endpoint, we have no choice but to poll (and per [the documentation](https://retro.umoiq.com/xmlFeedDocs/NextBusXMLFeed.pdf), no more than once every 10 seconds per agency).
-Polling from a Swim server is accomplished via [`Timers`]({% link _backend/timers.md %}).
+Polling from a Swim server is accomplished via [`Timers`]({% link _java_backend/timers.md %}).
 Potentially-blocking tasks (in this case, REST requests) run through `asyncStage()`.
 Combining these yields the following:
 
@@ -184,7 +184,7 @@ _Note: this union of timers and `asyncStage()` is a common pattern for request-r
 
 The code so far is fully capable of consuming the topic's data.
 We must now create entities -- `VehicleAgents` -- that can accept and process this data.
-Each will merely contain a `CommandLane` (to receive messages) and a [time series]({% link _backend/time-series.md %}) (to retain them).
+Each will merely contain a `CommandLane` (to receive messages) and a [time series]({% link _java_backend/time-series.md %}) (to retain them).
 
 ```java
 // VehicleAgent.java
diff --git a/src/_backend/http-lanes.md b/src/_java_backend/http-lanes.md
similarity index 95%
rename from src/_backend/http-lanes.md
rename to src/_java_backend/http-lanes.md
index 6ef2331..3bee772 100644
--- a/src/_backend/http-lanes.md
+++ b/src/_java_backend/http-lanes.md
@@ -6,11 +6,11 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/http_lanes
 redirect_from:
-  - /tutorials/http-lanes/
-  - /reference/http-lanes.html
+  - /java/tutorials/http-lanes/
+  - /java/reference/http-lanes.html
 ---
 
-In previous guides, we have seen how Swim applications consist of interconnected [Web Agents]({% link _backend/web-agents.md %}) with properties and methods in the form of [Lanes]({% link _backend/command-lanes.md %}).
+In previous guides, we have seen how Swim applications consist of interconnected [Web Agents]({% link _java_backend/web-agents.md %}) with properties and methods in the form of [Lanes]({% link _java_backend/command-lanes.md %}).
 
 **HTTP Lanes** accept HTTP requests and respond enabling Web Agents to expose **endpoints**. This allows Web Agent's state to be viewed or modified from outside of Swim applications through the use of **REST APIs**.
 
@@ -104,7 +104,7 @@ public class UnitAgent extends AbstractAgent {
 
 ### Content Type
 
-As well as **Recon**, HTTP Lanes also allow for different content types to be returned in the response body such as **Json**. Simply add the media type when setting the body of the HTTP response. 
+As well as **Recon**, HTTP Lanes also allow for different content types to be returned in the response body such as **Json**. Simply add the media type when setting the body of the HTTP response.
 
 Here we create a new lane in our previous example to return a Json response:
 
@@ -119,4 +119,3 @@ Here we create a new lane in our previous example to return a Json response:
 ### Try It Yourself
 
 A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/http_lanes).
-
diff --git a/src/_backend/index.md b/src/_java_backend/index.md
similarity index 82%
rename from src/_backend/index.md
rename to src/_java_backend/index.md
index 5e36d25..a805b36 100644
--- a/src/_backend/index.md
+++ b/src/_java_backend/index.md
@@ -1,6 +1,6 @@
 ---
 title: Backend
-permalink: /backend/
+permalink: /java/backend/
 layout: documentation
 description: "Backend SwimOS"
 toc: false
diff --git a/src/_backend/ingress-bridges.md b/src/_java_backend/ingress-bridges.md
similarity index 95%
rename from src/_backend/ingress-bridges.md
rename to src/_java_backend/ingress-bridges.md
index a652b9d..c272c52 100644
--- a/src/_backend/ingress-bridges.md
+++ b/src/_java_backend/ingress-bridges.md
@@ -6,8 +6,8 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/ingress_bridges
 redirect_from:
-  - /tutorials/ingress-bridges/
-  - /reference/ingress-bridges.html
+  - /java/tutorials/ingress-bridges/
+  - /java/reference/ingress-bridges.html
 ---
 
 Swim's built-in networking stack enables communication with other processes--which might themselves be other Swim servers. There are two directions of data flow: from Swim to external processes, and from external processes to Swim. This article discusses the latter.
@@ -27,7 +27,7 @@ Writes to a Swim server are most easily accomplished using a Swim client instanc
 
 Note that the second is simply the first with an intermediary process.
 
-Either way, the process that talks directly to the Swim server updates the server by either [sending commands]({% link _backend/command-lanes.md %}) or [writing to downlinks]({% link _backend/downlinks.md %}).
+Either way, the process that talks directly to the Swim server updates the server by either [sending commands]({% link _java_backend/command-lanes.md %}) or [writing to downlinks]({% link _java_backend/downlinks.md %}).
 
 ```java
 // swim/basic/SwimWriter.java
@@ -144,7 +144,7 @@ If the data source is not a Swim server and you still want something of a pull m
 
 - A secondary service pulls data, using **any networking protocol of your choice**, from the data source, then relays data to the Swim server using any of the "push-type" bridges discussed above.
 
-It is **not required** that this service run outside of the Swim server. There is a way to execute blocking calls within a server context without impacting Web Agent functionality. This feature exceeds the scope of this discussion, but a fully-worked example can be found in our [HTTP ingestion example]({% link _backend/http-ingestion.md %}).
+It is **not required** that this service run outside of the Swim server. There is a way to execute blocking calls within a server context without impacting Web Agent functionality. This feature exceeds the scope of this discussion, but a fully-worked example can be found in our [HTTP ingestion example]({% link _java_backend/http-ingestion.md %}).
 
 ### Try It Yourself
 
diff --git a/src/_backend/introspection.md b/src/_java_backend/introspection.md
similarity index 95%
rename from src/_backend/introspection.md
rename to src/_java_backend/introspection.md
index da37a51..dae15e2 100644
--- a/src/_backend/introspection.md
+++ b/src/_java_backend/introspection.md
@@ -6,10 +6,11 @@ group: Utilities
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/introspection
 redirect_from:
-  - /guides/introspection.html
+  - /java/guides/introspection.html
 ---
 
 Introspection allows you to obtain runtime information about a Swim server, including:
+
 - Compute and memory metrics
 - List running nodes
 - List lanes of a node
@@ -17,7 +18,7 @@ Introspection allows you to obtain runtime information about a Swim server, incl
 
 _We will be demonstrating introspection on the corresponding cookbook server and so use host `warp://localhost:9001`.
 Feel free to follow along or change commands to match your server.
-This guide uses the [`swim-cli`]({% link _backend/cli.md %}) extensively._ 
+This guide uses the [`swim-cli`]({% link _java_backend/cli.md %}) extensively._
 
 ## Enabling Introspection
 
@@ -27,14 +28,13 @@ Include the following line in a Swim application's `server.recon` config file to
 @kernel(class: "swim.meta.MetaKernel")
 ```
 
-This will start a `MetaKernel` responsible for opening additional nodes and endpoints providing meta information. 
+This will start a `MetaKernel` responsible for opening additional nodes and endpoints providing meta information.
 
 ## Meta Nodes
 
 Two types of meta node are now available for downlinking:
 
 - The `swim:meta:mesh` node, which provides server wide meta details.
-  
 - The `swim:meta:node/{node_uri}` nodes, which provide node specific meta details.
 
 These meta nodes behave similarly to normal nodes and so can be downlinked from within a swim application or using the `swim-cli`.
@@ -80,19 +80,17 @@ Output:
 ```
 
 We see that the server has several `building` and `room` nodes, we have a URI, start time and agent list for each.
-Notice the room nodes have two agents, a `RoomAgent` and `RoomSimulatorAgent` - see more on multiple agents in the [`traits`]({% link _backend/traits.md %}) reference.
+Notice the room nodes have two agents, a `RoomAgent` and `RoomSimulatorAgent` - see more on multiple agents in the [`traits`]({% link _java_backend/traits.md %}) reference.
 
 This lane can also list all child node URIs of a parent, giving the ability to list all nodes of a given type.
 We can do this by adding a parameter onto the `nodes` lane with `#` followed by the pattern of a node URI, ending with `/`.
 For clarity, here are some example parameters that can be used and their function:
 
 - `nodes#/`: List the first part of all node URIs (this will just be `/building` in the cookbook as all nodes are children).
-  
 - `nodes#/building/`: List all building nodes.
-  
 - `nodes#/building/2/room/`: List all room nodes in building 2.
 
-Using the second option as an example: 
+Using the second option as an example:
 
 ```
 swim-cli sync -h warp://localhost:9001 -n swim:meta:mesh -l nodes#/building/
@@ -151,4 +149,4 @@ Output:
 Swim provides a general purpose Introspection GUI, this is built upon the concepts above.
 It can be used to visualise a Swim server including nodes, lanes and pulse stats.
 
-Check out [`https://introspection.nstream.io/?host=warp://localhost:9001`](https://introspection.nstream.io/?host=warp://localhost:9001) while running the introspection cookbook or change the host parameter to point at your Swim server.
\ No newline at end of file
+Check out [`https://introspection.nstream.io/?host=warp://localhost:9001`](https://introspection.nstream.io/?host=warp://localhost:9001) while running the introspection cookbook or change the host parameter to point at your Swim server.
diff --git a/src/_backend/jms-ingestion.md b/src/_java_backend/jms-ingestion.md
similarity index 98%
rename from src/_backend/jms-ingestion.md
rename to src/_java_backend/jms-ingestion.md
index 237bce1..d652ec9 100644
--- a/src/_backend/jms-ingestion.md
+++ b/src/_java_backend/jms-ingestion.md
@@ -6,7 +6,7 @@ group: Data Ingestion
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/jms_ingestion
 redirect_from:
-  - /guides/jms-ingestion.html
+  - /java/guides/jms-ingestion.html
 ---
 
 This guide illustrates how to develop a Swim application that receives data from JMS and instantiates logic-performing Web Agents.
@@ -147,7 +147,7 @@ public class JmsAgent extends AbstractAgent {
 
 The code so far is fully capable of receiving messages from a topic.
 We must now create entities - `VehicleAgents` - that can accept and process this data.
-Each will merely contain a `CommandLane` (to receive messages) and a [time series]({% link _backend/time-series.md %}) (to retain them).
+Each will merely contain a `CommandLane` (to receive messages) and a [time series]({% link _java_backend/time-series.md %}) (to retain them).
 
 ```java
 // VehicleAgent.java
diff --git a/src/_backend/join-map-lanes.md b/src/_java_backend/join-map-lanes.md
similarity index 85%
rename from src/_backend/join-map-lanes.md
rename to src/_java_backend/join-map-lanes.md
index ce00bfd..7d80180 100644
--- a/src/_backend/join-map-lanes.md
+++ b/src/_java_backend/join-map-lanes.md
@@ -6,13 +6,13 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/join_map_lanes
 redirect_from:
-  - /tutorials/join-map-lanes/
-  - /reference/join-map-lanes.html
+  - /java/tutorials/join-map-lanes/
+  - /java/reference/join-map-lanes.html
 ---
 
-The [Join Value Lanes guide]({% link _backend/join-value-lanes.md %}) demonstrates Join Value Lanes which aggregate value lanes from many agents. Similar to **Join Value Lanes**, **Join Map Lanes** aggregate **Map Lanes** across multiple agents.
+The [Join Value Lanes guide]({% link _java_backend/join-value-lanes.md %}) demonstrates Join Value Lanes which aggregate value lanes from many agents. Similar to **Join Value Lanes**, **Join Map Lanes** aggregate **Map Lanes** across multiple agents.
 
-A **Join Map Lane** uses [downlinks]({% link _backend/links.md %}) to create permanent links to **Map Lanes** and exhibits the same behaviour as [Map Lanes]({% link _backend/map-lanes.md %}). Some additional properties are present:
+A **Join Map Lane** uses [downlinks]({% link _java_backend/links.md %}) to create permanent links to **Map Lanes** and exhibits the same behaviour as [Map Lanes]({% link _java_backend/map-lanes.md %}). Some additional properties are present:
 
 - Operations performed on a **Map Lane** are propagated via downlinks to the **Join Map Lane**.
 - A **link form** must be specified.
@@ -31,7 +31,7 @@ JoinMapLane<FormType, KeyType, ValueType> stateJoinMap = this.joinMapLane();
 ```
 
 For the purposes of this cookbook all three types will be **String**. A join map lane is a map that can aggregate entry sets of many map lanes using downlinks. If aggregating maps of different types, a sufficient type must be used - such as a String. **Join Map Lanes** can perform **put** and **remove** operations on the map instance but the operations are not propagated via the downlinks.
-    
+
 Usage of **Join Map Lanes** mandates downlinks to be opened to the lanes that are to be aggregated and this can be performed easily through the **didStart()** method of an agent.
 
 ```java
@@ -53,7 +53,7 @@ From here, we are able to use the lifecycle events that occur on other data stru
 
 ### A worked example
 
-In this example, we will work through joining three **Map Lanes** that hold information regarding US states and aggregate the data into a **Join Map Lane**. This aggregated data will have a **didUpdate()** callback registered that checks entries that are added to see if they exceed a threshold. If it is, then the data is logged. 
+In this example, we will work through joining three **Map Lanes** that hold information regarding US states and aggregate the data into a **Join Map Lane**. This aggregated data will have a **didUpdate()** callback registered that checks entries that are added to see if they exceed a threshold. If it is, then the data is logged.
 
 One agent, **StreetStatisticsAgent**, will store a given state's street data. **AggregatedStatisticsAgent** will aggregate all the **StreetStatisticsAgents** and is accessible through a **MapDownlink** which is used further on.
 
@@ -83,7 +83,7 @@ static class AggregatedStatisticsAgent extends AbstractAgent {
 }
 ```
 
-**Join Map Lanes** require downlinks to all of the **JoinMaps** that are to be aggregated and these can be opened using the agent's **didStart()** method; in this instance, the **didStart()** method is used for convenience, however, in more complex applications [command lanes]({% link _backend/command-lanes.md %}) would be more suitable. Here, downlinks are opened to three states using the Swim lane **'state'**.
+**Join Map Lanes** require downlinks to all of the **JoinMaps** that are to be aggregated and these can be opened using the agent's **didStart()** method; in this instance, the **didStart()** method is used for convenience, however, in more complex applications [command lanes]({% link _java_backend/command-lanes.md %}) would be more suitable. Here, downlinks are opened to three states using the Swim lane **'state'**.
 
 Bringing this together, a plane is required with the two previous agents and the appropriate lane URIs.
 
@@ -98,7 +98,7 @@ static class BasicPlane extends AbstractPlane {
 }
 ```
 
-By design, operations performed on a **Join Map Lane** are not propagated through the uplinks to the **Map Lanes**. Thus, the maps to be aggregated must be populated and not inversely. **Map Lanes** are opened on a plane as discussed in the [map lane]({% link _backend/map-lanes.md %}) cookbook and a **Join Map Lane** is no exception. This **Join Map Lane** logs streets that contain over 1000 residents using the **didUpdate()** method:
+By design, operations performed on a **Join Map Lane** are not propagated through the uplinks to the **Map Lanes**. Thus, the maps to be aggregated must be populated and not inversely. **Map Lanes** are opened on a plane as discussed in the [map lane]({% link _java_backend/map-lanes.md %}) cookbook and a **Join Map Lane** is no exception. This **Join Map Lane** logs streets that contain over 1000 residents using the **didUpdate()** method:
 
 ```java
 // swim/basic/CustomClient.java
diff --git a/src/_backend/join-value-lanes.md b/src/_java_backend/join-value-lanes.md
similarity index 95%
rename from src/_backend/join-value-lanes.md
rename to src/_java_backend/join-value-lanes.md
index fc2c1ac..ffc764a 100644
--- a/src/_backend/join-value-lanes.md
+++ b/src/_java_backend/join-value-lanes.md
@@ -6,17 +6,17 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/join_value_lanes
 redirect_from:
-  - /tutorials/join-value-lanes/
-  - /reference/join-value-lanes.html
+  - /java/tutorials/join-value-lanes/
+  - /java/reference/join-value-lanes.html
 ---
 
-In the [Value Lanes guide]({% link _backend/value-lanes.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+In the [Value Lanes guide]({% link _java_backend/value-lanes.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
 
 Lanes come in many flavors, but every lane type exposes:
 
 - A **means to act** on this lane
 - Customizable **lifecycle callbacks** that execute during the runtime of this action
-- Various means to **strongly type** (i.e. *parametrize*) the lane
+- Various means to **strongly type** (i.e. _parametrize_) the lane
 - Universal WARP **subscriptions** to this lane
 
 A **join value lane** uses **downlinks** to create permanent links to other value lanes and meets the following requirements:
@@ -97,17 +97,17 @@ import swim.structure.Value;
 public class RoomAgent extends AbstractAgent {
   @SwimLane ("lights")
   ValueLane<Boolean> lights = this.<Boolean>valueLane();
-  
+
   @Override
   public void didStart() {
     register();
   }
-  
+
   @SwimLane ("toggleLights")
   CommandLane<String> toggleLights = this.<String>commandLane().onCommand(msg -> {
     this.lights.set(!lights.get());
   });
-  
+
   private void register() {
     String buildingUri = "/building/" + this.getProp("building").stringValue();
     Value roomId = this.getProp("room");
@@ -138,7 +138,7 @@ public class BuildingAgent extends AbstractAgent {
                                                           Boolean oldValue) -> {
     System.out.println("The lights in room " + key + " are " + (newValue ? "off." : "on."));
   });
-  
+
   @SwimLane ("registerRoom")
   CommandLane<Value> registerRoom = this.<Value>commandLane().onCommand(room -> {
     String roomUri = "/" + this.getProp("name").stringValue() + "/" + room.stringValue();
@@ -164,12 +164,12 @@ import swim.structure.Form;
 class CustomClient {
 
   public static void main(String[] args) throws InterruptedException {
-    
+
     ClientRuntime swimClient = new ClientRuntime();
     swimClient.start();
     final String hostUri = "warp://localhost:9001";
     final String buildingUri = "/building/swim";
-  
+
     final MapDownlink<Integer, Boolean> link = swimClient.downlinkMap()
                                                         .keyForm(Form.forInteger())
                                                         .valueForm(Form.forBoolean())
@@ -177,21 +177,20 @@ class CustomClient {
                                                         .nodeUri(buildingUri)
                                                         .laneUri("lights")
                                                         .open();
-    
+
     Thread.sleep(2000);
     System.out.println("Join value lane");
     link.get().forEach((key, value) -> System.out.println(key + ":" + value));
-  
-  
+
+
     System.out.println("Will shut down client in 2 seconds");
     Thread.sleep(2000);
-    
+
     swimClient.stop();
   }
 }
 ```
-      
+
 ### Try It Yourself
 
 A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/join_map_lanes).
-
diff --git a/src/_backend/kafka-ingestion.md b/src/_java_backend/kafka-ingestion.md
similarity index 98%
rename from src/_backend/kafka-ingestion.md
rename to src/_java_backend/kafka-ingestion.md
index bd78626..6514a3d 100644
--- a/src/_backend/kafka-ingestion.md
+++ b/src/_java_backend/kafka-ingestion.md
@@ -6,7 +6,7 @@ group: Data Ingestion
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/kafka_ingestion
 redirect_from:
-  - /guides/kafka-ingestion.html
+  - /java/guides/kafka-ingestion.html
 ---
 
 This guide illustrates how to develop a Swim application that ingests data from Kafka topics and instantiates logic-performing Web Agents.
@@ -31,7 +31,7 @@ Messages in the topic take the following structure:
 
 - `key`: a unique String identifying this vehicle
 - `value`: a JSON string that looks like:
-  
+
 ```
 {
   "id": (string (same as key)),
@@ -148,7 +148,7 @@ _The current approach has the advantage of "fast-failing" the process, avoiding
 
 The code so far is fully capable of consuming the topic's data.
 We must now create entities -- `VehicleAgents` -- that can accept and process this data.
-Each will merely contain a `CommandLane` (to receive messages) and a [time series]({% link _backend/time-series.md %}) (to retain them).
+Each will merely contain a `CommandLane` (to receive messages) and a [time series]({% link _java_backend/time-series.md %}) (to retain them).
 
 ```java
 // VehicleAgent.java
@@ -184,7 +184,7 @@ import swim.json.Json;
 import swim.structure.Value;
 
 public class KafkaConsumingAgent extends AbstractAgent {
-  
+
   private final AbstractTask infiniteConsumingTask = asyncStage().task(new AbstractTask() {
 
         @Override
diff --git a/src/_backend/lane-organization.md b/src/_java_backend/lane-organization.md
similarity index 88%
rename from src/_backend/lane-organization.md
rename to src/_java_backend/lane-organization.md
index 521ac46..05a1e81 100644
--- a/src/_backend/lane-organization.md
+++ b/src/_java_backend/lane-organization.md
@@ -5,7 +5,7 @@ description: Best practices for lane organization
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /concepts/lane-organization.html
+  - /java/concepts/lane-organization.html
 ---
 
 Lanes expose an API for agents, allowing the state of an agent to be downlinked and streamed.
@@ -15,11 +15,11 @@ In this guide we will discuss the different lane types, what should be stored in
 
 ## Value Lanes
 
-_For more details on usage and syntax see the [Value Lanes reference]({% link _backend/value-lanes.md %})._
+_For more details on usage and syntax see the [Value Lanes reference]({% link _java_backend/value-lanes.md %})._
 
 Value lanes are the simplest form of a lane as they store flat data, a single **scalar value**.
 While this may seem limiting, remember that the scalar value can be an object with multiple fields, we commonly use the `Value` type as it is general purpose and all lanes are backed by it.
-If the data has a strict structure, consider strongly typing the lanes, see [Forms]({% link _backend/forms.md %}).
+If the data has a strict structure, consider strongly typing the lanes, see [Forms]({% link _java_backend/forms.md %}).
 
 Value lanes should be organized into groups of highly related data.
 Frequency of change should also be considered, it is not efficient to send fields that rarely update with every state change of the agent.
@@ -36,14 +36,14 @@ If your agent design stores `n` attributes in a single value lane, updates to a
 Let's say we have an agent representing something with a geographic location that can move (car, ship, plane).
 
 - The **status** lane will store current values of sensors, metrics and kpis (speed, altitude, fuel, ETA).
-Current status fields change frequently and so this lane allows for real time insights into the agents performance.
+  Current status fields change frequently and so this lane allows for real time insights into the agents performance.
 
 - The **info** lane will store some metadata about the agent (ID, model number, make, brand).
-Metadata about the agent does not change frequently and so while it should still be available, we do not need to receive it with every state change, hence we separate it from the 'status' lane.
+  Metadata about the agent does not change frequently and so while it should still be available, we do not need to receive it with every state change, hence we separate it from the 'status' lane.
 
 - The **geo** lane will store key fields for rendering the agent on a map GUI (longitude, latitude, ID, colour).
-This lane is specifically created for a component downstream, a map of all the agents.
-The map only updates when an agent moves, and so we cherry-pick the fields the map requires to expose a bespoke lane.
+  This lane is specifically created for a component downstream, a map of all the agents.
+  The map only updates when an agent moves, and so we cherry-pick the fields the map requires to expose a bespoke lane.
 
 ```java
 @SwimLane("status")
@@ -58,7 +58,7 @@ public ValueLane<Value> geo = this.<Value>valueLane();
 
 ## Map Lanes
 
-_For more details on usage and syntax see the [Map Lanes reference]({% link _backend/map-lanes.md %})._
+_For more details on usage and syntax see the [Map Lanes reference]({% link _java_backend/map-lanes.md %})._
 
 Map Lanes store **collections** of data ordered by a **unique key** (key-value pairs), hence it is a little more intuitive what to store in map lanes.
 
@@ -89,13 +89,13 @@ public MapLane<Integer, String> schedule = this.<Integer, String>mapLane();
 
 ## Join Value Lanes
 
-_For more details on usage and syntax see the [Join Value Lanes reference]({% link _backend/join-value-lanes.md %})._
+_For more details on usage and syntax see the [Join Value Lanes reference]({% link _java_backend/join-value-lanes.md %})._
 
 Join value lanes are lanes that **aggregate** value lanes of other agents using downlinks, creating **one-to-many relationships** between agents.
 They essentially create a map lane, the key being some unique identifier of an agent (node URI being the obvious candidate), the value being the current value of another agent's value lane.
 The map can also be used to calculate aggregate metrics across the whole set of child agents.
 
-For a guide on how to implement an aggregate agent see the [aggregations guide]({% link _backend/aggregations.md %}).
+For a guide on how to implement an aggregate agent see the [aggregations guide]({% link _java_backend/aggregations.md %}).
 
 **Example**
 
@@ -114,7 +114,7 @@ protected JoinValueLane<Value, Value> orders = this.<Value, Value>joinValueLane(
 
 ## Demand Value Lanes
 
-_For more details on usage and syntax see the [Demand Value Lanes reference]({% link _backend/demand-value-lanes.md %})._
+_For more details on usage and syntax see the [Demand Value Lanes reference]({% link _java_backend/demand-value-lanes.md %})._
 
 A demand value lane does not store a value, instead they are backed by a value lane and retrieve the value purely **on demand**.
 Demand value lanes **lazily generate events** for the value lane, only when there is an uplink ready to receive the event.
@@ -139,7 +139,7 @@ public DemandLane<String> data = this.<String>demandLane().onCue(uplink -> uncom
 
 ## Demand Map Lanes
 
-_For more details on usage and syntax see the [Demand Map Lanes reference]({% link _backend/demand-map-lanes.md %})._
+_For more details on usage and syntax see the [Demand Map Lanes reference]({% link _java_backend/demand-map-lanes.md %})._
 
 A demand map lane does not store a collection, instead they are backed by a map lane and retrieve values purely **on demand**.
 Demand map lanes **lazily generate events** for the map lane, only when there is an uplink ready to receive the event.
@@ -168,7 +168,7 @@ public DemandMapLane<String, Value> usersQuery = this.<String, Value>demandMapLa
     })
     .onSync(uplink -> {
         final String username = uplink.laneUri().query().get("username");
-        return (this.users.containsKey(username)) ? 
+        return (this.users.containsKey(username)) ?
             Collections.singletonList(username).iterator() : Collections.emptyIterator();
     });
-```
\ No newline at end of file
+```
diff --git a/src/_backend/lanes.md b/src/_java_backend/lanes.md
similarity index 79%
rename from src/_backend/lanes.md
rename to src/_java_backend/lanes.md
index fd00efa..b87f82b 100644
--- a/src/_backend/lanes.md
+++ b/src/_java_backend/lanes.md
@@ -5,8 +5,8 @@ description: "Store state in Web Agents and trigger actions on Web Agents using
 group: Reference
 layout: documentation
 redirect_from:
-  - /concepts/lanes/
-  - /reference/lanes.html
+  - /java/concepts/lanes/
+  - /java/reference/lanes.html
 ---
 
 Distributed objects aren't very useful without properties to store state, and methods to trigger actions. Enter **lanes**. Each Web Agent has a set of named lanes, representing the properties and methods of the Web Agent.
@@ -51,4 +51,4 @@ class Person {
 
 Not much difference. But the former instantiates distributable, automatically persistent, continuously consistent Web Agents, accessible via multiplexed streaming APIs. And the latter instantiates ephemeral Java objects.
 
-Jump ahead to [links]({% link _backend/links.md %}) to find out more about streaming APIs. Dive into the [tutorials]({% link _tutorials/index.md %}) to see how lanes are used in practice. Or read on to learn more about the various kinds of lanes available in Swim.
+Jump ahead to [links]({% link _java_backend/links.md %}) to find out more about streaming APIs. Dive into the [tutorials]({% link _java_tutorials/index.md %}) to see how lanes are used in practice. Or read on to learn more about the various kinds of lanes available in Swim.
diff --git a/src/_backend/links.md b/src/_java_backend/links.md
similarity index 86%
rename from src/_backend/links.md
rename to src/_java_backend/links.md
index c2639fb..2ea00eb 100644
--- a/src/_backend/links.md
+++ b/src/_java_backend/links.md
@@ -5,8 +5,8 @@ description: "Learn how downlinks form references to the state of Web Agents."
 group: Reference
 layout: documentation
 redirect_from:
-  - /concepts/links/
-  - /reference/links.html
+  - /java/concepts/links/
+  - /java/reference/links.html
 ---
 
 Central to programming is the ability to create pointers, or references, to things. Pointers are much more than memory addresses. Pointers often represent usage restrictions (think `const`, or `volatile`). And modern CPUs even use pointers as caching hints, pre-fetching data that might eventually be used in a computation. Swim takes the idea of pointers to the next level, enabling streaming references to the lanes of remote Web Agents, with strong consistency guarantees.
@@ -54,4 +54,4 @@ yourName.close();
 
 Links are point-to-point, and unbuffered, making them real-time within the latency of the network and CPU.
 
-Jump ahead to [Recon]({% link _backend/recon.md %}) to find out how lanes and links represent data internally. Dive into the [tutorials]({% link _tutorials/index.md %}) to see how links get used in a real application. Or read on to learn more about the different kinds of links, their properties, and their guarantees.
+Jump ahead to [Recon]({% link _java_backend/recon.md %}) to find out how lanes and links represent data internally. Dive into the [tutorials]({% link _java_tutorials/index.md %}) to see how links get used in a real application. Or read on to learn more about the different kinds of links, their properties, and their guarantees.
diff --git a/src/_backend/map-lanes.md b/src/_java_backend/map-lanes.md
similarity index 96%
rename from src/_backend/map-lanes.md
rename to src/_java_backend/map-lanes.md
index bc78faa..de0c32a 100644
--- a/src/_backend/map-lanes.md
+++ b/src/_java_backend/map-lanes.md
@@ -6,11 +6,11 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/map_lanes
 redirect_from:
-  - /tutorials/map-lanes/
-  - /reference/map-lanes.html
+  - /java/tutorials/map-lanes/
+  - /java/reference/map-lanes.html
 ---
 
-In the [Web Agents guide]({% link _backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+In the [Web Agents guide]({% link _java_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
 
 Lanes come in many flavors, but every lane type exposes:
 
@@ -61,7 +61,7 @@ The `AbstractAgent` class comes with utility methods to construct runnable lanes
   - `void didUpdate(K key, V newValue, V oldValue)`: executed every time a key, value pair is placed in the lane
   - `void didRemove(K key, V oldValue)`: executed every time a key is removed from the lane
   - `void didDrop(int dropCount)`: executed every time `drop()` is invoked on the lane
-    
+
 Should you define a constructor for your web agent, you must explicitly provide a default constructor and handle the initialization of all member variables declared by your Web Agent. However, it is not recommended to define any constructors. There is a `didStart()` lifecycle method that allows you to do post-initialization processing.
 
 ```java
@@ -124,7 +124,7 @@ public class UnitAgent extends AbstractAgent {
 
 Direct communication with value lanes is instead accomplished through **downlinks**. Downlinks are WARP subscriptions to lanes. They come in many flavors, but subscriptions to map lanes can only be accomplished through **map downlinks** and, to a more limited extent, **event downlinks**.
 
-Further reading: [Command Lanes]({% link _backend/command-lanes.md %}), [Downlinks]({% link _backend/downlinks.md %})
+Further reading: [Command Lanes]({% link _java_backend/command-lanes.md %}), [Downlinks]({% link _java_backend/downlinks.md %})
 
 ### Writing to Map Lanes
 
@@ -212,4 +212,3 @@ class CustomClient {
 ### Try It Yourself
 
 A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/map_lanes).
-
diff --git a/src/_backend/mongodb-ingestion.md b/src/_java_backend/mongodb-ingestion.md
similarity index 96%
rename from src/_backend/mongodb-ingestion.md
rename to src/_java_backend/mongodb-ingestion.md
index 2b6626e..d01f6ac 100644
--- a/src/_backend/mongodb-ingestion.md
+++ b/src/_java_backend/mongodb-ingestion.md
@@ -6,7 +6,7 @@ group: Data Ingestion
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/mongodb_ingestion
 redirect_from:
-  - /guides/mongodb-ingestion.html
+  - /java/guides/mongodb-ingestion.html
 ---
 
 This guide illustrates how to develop a Swim application that polls data from MongoDB and instantiates logic-performing Web Agents.
@@ -76,7 +76,7 @@ public final class Assets {
 
 `Assets.mongoClient` will be the bridge between the Mongo database and the Swim server.
 
-We could instantiate a client locally in the agent that needs to poll, however, `MongoClient` acts as a connection pool and so this allows multiple agents to use the client concurrently. 
+We could instantiate a client locally in the agent that needs to poll, however, `MongoClient` acts as a connection pool and so this allows multiple agents to use the client concurrently.
 
 ### Step 2: `MongoDbPollingAgent` Implementation
 
@@ -84,6 +84,7 @@ Now we are going to implement the web agent responsible for polling the database
 
 Let's first create a method that defines the query we are going to run.
 In this case we are going to use the MongoDB `find` operation to fetch every document in the collection - for more advanced queries check out the [MongoDB documentation](https://www.mongodb.com/docs/drivers/java/sync/current/usage-examples/find/).
+
 ```java
 private FindIterable<Document> find() {
     return Assets.mongoClient().getDatabase("myDatabase")
@@ -113,7 +114,8 @@ In this case we are going to extract a unique identifier (`id`) to build a node
 
 We finish the agent by scheduling a poll to run asynchronously of the agent thread on agent startup:
 
-_See the [timers guide]({% link _backend/timers.md %}) for more information on how we could poll continuously with a given time interval._
+_See the [timers guide]({% link _java_backend/timers.md %}) for more information on how we could poll continuously with a given time interval._
+
 ```java
 // MongoDbPollingAgent
 import com.mongodb.client.FindIterable;
diff --git a/src/_backend/planes.md b/src/_java_backend/planes.md
similarity index 93%
rename from src/_backend/planes.md
rename to src/_java_backend/planes.md
index 2aa2160..592d7f1 100644
--- a/src/_backend/planes.md
+++ b/src/_java_backend/planes.md
@@ -6,11 +6,11 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/planes
 redirect_from:
-  - /tutorials/planes/
-  - /reference/planes.html
+  - /java/tutorials/planes/
+  - /java/reference/planes.html
 ---
 
-In the [Web Agents guide]({% link _backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects** and **lanes** are **fields**. Swim **planes** can, loosely, be seen as a **shared context** for a group of Web Agents, somewhat analogous to **scopes** but with more runtime responsibilities.
+In the [Web Agents guide]({% link _java_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects** and **lanes** are **fields**. Swim **planes** can, loosely, be seen as a **shared context** for a group of Web Agents, somewhat analogous to **scopes** but with more runtime responsibilities.
 
 More specifically, every plane:
 
@@ -270,5 +270,3 @@ public class BasicPlane extends AbstractPlane {
 ### Try It Yourself
 
 A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/planes).
-
-
diff --git a/src/_backend/pulsar-ingestion.md b/src/_java_backend/pulsar-ingestion.md
similarity index 98%
rename from src/_backend/pulsar-ingestion.md
rename to src/_java_backend/pulsar-ingestion.md
index 0b9b314..a2ce8c1 100644
--- a/src/_backend/pulsar-ingestion.md
+++ b/src/_java_backend/pulsar-ingestion.md
@@ -6,7 +6,7 @@ group: Data Ingestion
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/pulsar_ingestion
 redirect_from:
-  - /guides/pulsar-ingestion.html
+  - /java/guides/pulsar-ingestion.html
 ---
 
 This guide illustrates how to develop a Swim application that ingests data from Pulsar topics and instantiates logic-performing Web Agents.
@@ -129,7 +129,7 @@ _Note: if your [subscription type](https://pulsar.apache.org/docs/3.1.x/concepts
 
 The code so far is fully capable of consuming the topic's data.
 We must now create entities -- `VehicleAgents` -- that can accept and process this data.
-Each will merely contain a `CommandLane` (to receive messages) and a [time series]({% link _backend/time-series.md %}) (to retain them).
+Each will merely contain a `CommandLane` (to receive messages) and a [time series]({% link _java_backend/time-series.md %}) (to retain them).
 
 ```java
 // VehicleAgent.java
diff --git a/src/_backend/recon.md b/src/_java_backend/recon.md
similarity index 71%
rename from src/_backend/recon.md
rename to src/_java_backend/recon.md
index 59c8304..0f31099 100644
--- a/src/_backend/recon.md
+++ b/src/_java_backend/recon.md
@@ -5,8 +5,8 @@ description: "Learn about the structural data model called Recon, which is used
 group: Reference
 layout: documentation
 redirect_from:
-  - /concepts/recon/
-  - /reference/recon.html
+  - /java/concepts/recon/
+  - /java/reference/recon.html
 ---
 
 Web Agents and their lanes define the entities and associated operations of a streaming API. But this definition is incomplete without also defining the data structures supported by each operation. Swim uses a simple, structural data model, called **Recon**, to exchange streaming messages.
@@ -20,4 +20,4 @@ Recon was designed to meet a number of key requirements:
 - **simple grammar** to facilitate many compatible implementations
 - **universal data type** compatible with JSON, XML, and other popular data languages
 
-Jump ahead to [WARP]({% link _backend/warp.md %}) to see how Recon is used as the wire format for a multiplexed streaming network protocol. Dive into the [tutorials]({% link _tutorials/index.md %}) to see how Recon is used in practice to serialize application objects. Or read on to learn more about the unique properties of Recon.
+Jump ahead to [WARP]({% link _java_backend/warp.md %}) to see how Recon is used as the wire format for a multiplexed streaming network protocol. Dive into the [tutorials]({% link _java_tutorials/index.md %}) to see how Recon is used in practice to serialize application objects. Or read on to learn more about the unique properties of Recon.
diff --git a/src/_backend/server-downlinks.md b/src/_java_backend/server-downlinks.md
similarity index 93%
rename from src/_backend/server-downlinks.md
rename to src/_java_backend/server-downlinks.md
index b7d453b..0d1ccdf 100644
--- a/src/_backend/server-downlinks.md
+++ b/src/_java_backend/server-downlinks.md
@@ -6,11 +6,11 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/server_downlinks
 redirect_from:
-  - /tutorials/server-downlinks/
-  - /reference/server-downlinks.html
+  - /java/tutorials/server-downlinks/
+  - /java/reference/server-downlinks.html
 ---
 
-In the [Downlinks guide]({% link _backend/downlinks.md %}), we discuss **downlinks** - bidirectionally-streaming, persistent **subscriptions** to lanes - and went through an example of a client-side downlink. This guide will showcase downlinks between two Swim servers.
+In the [Downlinks guide]({% link _java_backend/downlinks.md %}), we discuss **downlinks** - bidirectionally-streaming, persistent **subscriptions** to lanes - and went through an example of a client-side downlink. This guide will showcase downlinks between two Swim servers.
 
 Server-side downlinks provide a simple and efficient way to integrate Swim applications allowing them to be linked or chained together with ease.
 
@@ -84,7 +84,7 @@ public class SupplierPlane extends AbstractPlane {
         .didSet((newValue, oldValue) -> {
           logMessage("latest supply id received at warehouse: " + newValue);
         }).open();
-  } 
+  }
 }
 ```
 
@@ -125,7 +125,7 @@ public class CustomerAgent extends AbstractAgent {
 }
 ```
 
-Client-side downlinks have been showcased in the [Downlinks guide]({% link _backend/downlinks.md %}).
+Client-side downlinks have been showcased in the [Downlinks guide]({% link _java_backend/downlinks.md %}).
 
 ### Try It Yourself
 
diff --git a/src/_backend/summary-statistics.md b/src/_java_backend/summary-statistics.md
similarity index 86%
rename from src/_backend/summary-statistics.md
rename to src/_java_backend/summary-statistics.md
index 5bf36dd..a5b931c 100644
--- a/src/_backend/summary-statistics.md
+++ b/src/_java_backend/summary-statistics.md
@@ -6,7 +6,7 @@ group: Swim Apps
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/summary_statistics
 redirect_from:
-  - /guides/summary-statistics.html
+  - /java/guides/summary-statistics.html
 ---
 
 Real-time applications frequently need to produce summaries of ingested data.
@@ -60,7 +60,7 @@ public abstract class AbstractTowerAgent extends AbstractAgent {
 ## Stream-Optimized Algorithms
 
 Efficiency is critical if we call `updateSummary()` against every incoming message, especially if message volumes are high.
-Running [offline algorithms](https://en.wikipedia.org/wiki/Online_algorithm) against a [time series]({% link _backend/time-series.md %}) that contains every received message can compute _any_ (solvable) statistic of interest, but this approach incurs linearly increasing memory and time costs.
+Running [offline algorithms](https://en.wikipedia.org/wiki/Online_algorithm) against a [time series]({% link _java_backend/time-series.md %}) that contains every received message can compute _any_ (solvable) statistic of interest, but this approach incurs linearly increasing memory and time costs.
 
 Suppose that each `TowerAgent` must report:
 
@@ -167,7 +167,7 @@ public class TowerAgent extends AbstractTowerAgent {
 }
 ```
 
-_Note: While we discourage reliance on it for computations, we could easily attach a [time series]({% link _backend/time-series.md %}) of message history to `TowerAgent` (or its variations described in the upcoming sections)._
+_Note: While we discourage reliance on it for computations, we could easily attach a [time series]({% link _java_backend/time-series.md %}) of message history to `TowerAgent` (or its variations described in the upcoming sections)._
 _Doing so instantiates two sets of streaming APIs: one for comprehensive statistics, and one for individual events._
 _This may be a valuable addition, especially when combined with a retention policy that retains only recent or interesting historical events._
 
@@ -301,29 +301,34 @@ A few things to note:
 - Running the `Main` class runs both a Swim server _and_ a simulator that feeds with data.
 - `src/main/resources/server.recon` defines routing that activates `TowerAgent`, `BucketedTowerAgent`, and `WindowedTowerAgent` all at once to facilitate exploration; in a real application, you would likely pick a single implementation.
 
-The following [`swim-cli`]({% link _backend/cli.md %}) commands are available while the process runs (replace `$ID` instances with either `2350` or `2171`):
+The following [`swim-cli`]({% link _java_backend/cli.md %}) commands are available while the process runs (replace `$ID` instances with either `2350` or `2171`):
 
 - Subscribing to a `TowerAgent` instance's `summary` lane
-    ```
-    % swim-cli sync -h warp://localhost:9001 -n /tower/$ID -l summary
-
-    {count:6,min:10.522381743242732,max:22.28527569332349,avg:17.403808512841756,variance:17.16435437538436,failures:1}
-    {count:7,min:10.522381743242732,max:23.042896596076552,avg:18.20939252473244,variance:18.6060973516128,failures:1}
-    {count:8,min:10.522381743242732,max:23.042896596076552,avg:17.689421621696006,variance:18.172923362692888,failures:3}
-    ...
-    ```
+
+  ```
+  % swim-cli sync -h warp://localhost:9001 -n /tower/$ID -l summary
+
+  {count:6,min:10.522381743242732,max:22.28527569332349,avg:17.403808512841756,variance:17.16435437538436,failures:1}
+  {count:7,min:10.522381743242732,max:23.042896596076552,avg:18.20939252473244,variance:18.6060973516128,failures:1}
+  {count:8,min:10.522381743242732,max:23.042896596076552,avg:17.689421621696006,variance:18.172923362692888,failures:3}
+  ...
+  ```
+
 - Subscribing to a `BucketedTowerAgent` instance's `summaries` lane
-    ```
-    % swim-cli sync -h warp://localhost:9001 -n /towerB/$ID -l summaries
-
-    @update(key:1692679380000){count:29,min:10.77128446925376,max:23.24959464873697,avg:16.2544517182087,variance:14.289407826056422,failures:13}
-    @update(key:1692679440000){count:30,min:13.118910710309262,max:25.28277927585947,avg:19.02977006553927,variance:12.15474919075009,failures:13}
-    @update(key:1692679500000){count:24,min:11.35274353757999,max:24.775153946326895,avg:18.213836505473765,variance:16.033697773471467,failures:12}
-    @update(key:1692679500000){count:25,min:11.35274353757999,max:24.775153946326895,avg:18.41973124051554,variance:16.409773268562738,failures:12}
-    ```
+
+  ```
+  % swim-cli sync -h warp://localhost:9001 -n /towerB/$ID -l summaries
+
+  @update(key:1692679380000){count:29,min:10.77128446925376,max:23.24959464873697,avg:16.2544517182087,variance:14.289407826056422,failures:13}
+  @update(key:1692679440000){count:30,min:13.118910710309262,max:25.28277927585947,avg:19.02977006553927,variance:12.15474919075009,failures:13}
+  @update(key:1692679500000){count:24,min:11.35274353757999,max:24.775153946326895,avg:18.213836505473765,variance:16.033697773471467,failures:12}
+  @update(key:1692679500000){count:25,min:11.35274353757999,max:24.775153946326895,avg:18.41973124051554,variance:16.409773268562738,failures:12}
+  ```
+
 - Subscribing to a `WindowedTowerAgent` instance's `summaries` lane
-    ```
-    % swim-cli sync -h warp://localhost:9001 -n /towerW/$ID -l summaries
 
-    (output similar to previous command)
-    ```
+  ```
+  % swim-cli sync -h warp://localhost:9001 -n /towerW/$ID -l summaries
+
+  (output similar to previous command)
+  ```
diff --git a/src/_backend/swim-create.md b/src/_java_backend/swim-create.md
similarity index 96%
rename from src/_backend/swim-create.md
rename to src/_java_backend/swim-create.md
index c0c40f3..d72158c 100644
--- a/src/_backend/swim-create.md
+++ b/src/_java_backend/swim-create.md
@@ -5,7 +5,7 @@ description: "How to bootstrap a Swim Application"
 group: Utilities
 layout: documentation
 redirect_from:
-  - /guides/swim-create.html
+  - /java/guides/swim-create.html
 ---
 
 The swim-create CLI tool lets you get started quickly by creating a basic skeleton for a swim project.
@@ -13,6 +13,7 @@ The swim-create CLI tool lets you get started quickly by creating a basic skelet
 ### Installation
 
 To install the latest version of the CLI tool you could run:
+
 ```bash
 curl -L https://github.com/nstreamio/swim-create/releases/latest/download/swim-create-x86_64-unknown-linux-gnu.tar.gz | sudo tar -xz -C /usr/local/bin
 ```
@@ -22,6 +23,7 @@ or alternatively download the latest release from: [https://github.com/nstreamio
 ### Usage
 
 You can then create a swim project using:
+
 ```bash
 swim-create <PROJECT_NAME>
 ```
@@ -36,4 +38,4 @@ A brief description of the most important files and their function:
 
 `server.recon` - Contains information about the Swim plane and the port for the Swim server.
 
-`MainPlane.java` - Is the Swim plane definition and the entry point.
\ No newline at end of file
+`MainPlane.java` - Is the Swim plane definition and the entry point.
diff --git a/src/_backend/swim-libraries.md b/src/_java_backend/swim-libraries.md
similarity index 87%
rename from src/_backend/swim-libraries.md
rename to src/_java_backend/swim-libraries.md
index 8a0b63d..2692b81 100644
--- a/src/_backend/swim-libraries.md
+++ b/src/_java_backend/swim-libraries.md
@@ -5,8 +5,8 @@ description: "Use SwimOS back-end and front-end components to build streaming da
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /start/
-  - /reference/swim-libraries.html
+  - /java/start/
+  - /java/reference/swim-libraries.html
 ---
 
 Swim implements a complete, self-contained, distributed application stack in an embeddable software library. To develop server-side Swim apps, add the [swim-api](https://github.com/swimos/swim/tree/main/swim-java/swim-runtime/swim-host/swim.api) library to your Java project. To write a JavaScript client application, install the [@swim/client](https://www.npmjs.com/package/@swim/client) library from NPM. Select one of the boxes below (or scroll down) to get started with Swim.
@@ -31,7 +31,7 @@ Swim implements a complete, self-contained, distributed application stack in an
   <!-- <p class="release-notes"><a href="">View Release Notes</a></p>-->
 <!-- </div> -->
 
-To try Swim, check out one of our step-by-step [tutorials]({% link _tutorials/index.md %}). To build your own app, try cloning a [starter application](https://github.com/swimos/tutorial). Or continue reading to learn more about how to get started with Swim.
+To try Swim, check out one of our step-by-step [tutorials]({% link _java_tutorials/index.md %}). To build your own app, try cloning a [starter application](https://github.com/swimos/tutorial). Or continue reading to learn more about how to get started with Swim.
 
 ### Java Server Quick Start
 
@@ -43,7 +43,6 @@ name: "swim-server",
 version: "4.2.14"
 ```
 
-
 ### Java Client Quick Start
 
 The Swim Java Client is a minimal WARP streaming API client.
@@ -66,4 +65,4 @@ Visit the [**frontend documentation**](/frontend) for more on how to write a Jav
 
 ### Next Steps
 
-Continue reading to tryout step-by-step lessons with Swim. Or dive into the core Swim [concepts]({% link _backend/index.md %}).
+Continue reading to tryout step-by-step lessons with Swim. Or dive into the core Swim [concepts]({% link _java_backend/index.md %}).
diff --git a/src/_backend/time-series.md b/src/_java_backend/time-series.md
similarity index 91%
rename from src/_backend/time-series.md
rename to src/_java_backend/time-series.md
index 299a0c6..273387b 100644
--- a/src/_backend/time-series.md
+++ b/src/_java_backend/time-series.md
@@ -6,14 +6,14 @@ group: Swim Apps
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/time_series
 redirect_from:
-  - /guides/time-series.html
+  - /java/guides/time-series.html
 ---
 
 A common form of data is time series data - that is data indexed by time (timestamped).
 
 ## Representation
 
-Time series data is a perfect candidate for a Swim [`MapLane`]({% link _backend/map-lanes.md %}).
+Time series data is a perfect candidate for a Swim [`MapLane`]({% link _java_backend/map-lanes.md %}).
 Using `Long` as the key type, you can create a streaming map indexed by timestamp:
 
 ```java
@@ -23,7 +23,7 @@ public MapLane<Long, Value> history = this.<Long, Value>mapLane();
 
 This will create an empty map on agent instantiation with the name `history`.
 In this example the data is stored as Swim `Value`s, but this can be changed to any type
-(built-ins trivially, and custom types by using [`Forms`]({% link _backend/forms.md %})).
+(built-ins trivially, and custom types by using [`Forms`]({% link _java_backend/forms.md %})).
 
 ## Adding Data
 
@@ -47,8 +47,8 @@ We can now make use of a `MapLane`'s callback functions to maintain the map and
 
 We can implement a policy where the map will only store the **N** most recent records.
 
-First we create a method that when called will trim the map to the desired size. 
-As `MapLane`s are ordered by key we can use the `drop(int count)` method to drop the oldest `count` records. 
+First we create a method that when called will trim the map to the desired size.
+As `MapLane`s are ordered by key we can use the `drop(int count)` method to drop the oldest `count` records.
 
 Next we just call the method from the `history` lane's `didUpdate` callback, this will trim the map after a new record is added.
 
@@ -141,7 +141,7 @@ Once we reach a record more recent than the cut-off time, we can stop.
 
 _Note: Unlike the previous section, it is not sufficient to just call this method whenever a new record is added - we still want to continue checking for old records, even if no new records are added._
 
-Next we are going to create and manage a [`Timer`]({% link _backend/timers.md %}) that will handle the calling of the `trimHistory()` method we just created.
+Next we are going to create and manage a [`Timer`]({% link _java_backend/timers.md %}) that will handle the calling of the `trimHistory()` method we just created.
 Ideally we want to manage one timer and that timer needs to trigger as soon as a record needs to be removed.
 
 Calculating the time until the next record needs to be dropped can be done by taking the oldest record time (calling `firstKey()` on the lane) adding maximum age of a record, then subtracting the current time.
@@ -156,7 +156,7 @@ Using this calculated time we can now make use of the web agent's `setTimer(long
   private void rescheduleNextTrim() {
     final long timeUntilNextTrim = (this.history.firstKey() + MAX_HISTORY_TIME_MS) - System.currentTimeMillis();
     this.timer = setTimer(timeUntilNextTrim, this::trimHistory);
-    
+
   }
 ```
 
@@ -164,13 +164,13 @@ We call the `rescheduleNextTrim()` method we just created from the `history` lan
 
 Finally, we need to account for a few things:
 
-- If two records are added in quick succession, `rescheduleNextTrim()` will be called twice, creating two timers. 
-To prevent this we add a check at the start of `rescheduleNextTrim()`, if there is already a timer scheduled, do nothing.
-- Currently, after the timer triggers `trimHistory()`, it is not called again until a new record is added. 
-What we would like to happen is for the timer to reschedule itself if the map is not empty after it is finished trimming.
-Adding a call to `rescheduleNextTrim()` before the `break` in our loop will have this affect.
+- If two records are added in quick succession, `rescheduleNextTrim()` will be called twice, creating two timers.
+  To prevent this we add a check at the start of `rescheduleNextTrim()`, if there is already a timer scheduled, do nothing.
+- Currently, after the timer triggers `trimHistory()`, it is not called again until a new record is added.
+  What we would like to happen is for the timer to reschedule itself if the map is not empty after it is finished trimming.
+  Adding a call to `rescheduleNextTrim()` before the `break` in our loop will have this affect.
 - It is possible to obtain a negative number when calculating the delay for the timer - meaning the oldest record should be removed immediately.
-We simply check for this and call `trimHistory()` if the number calculated is less than zero.
+  We simply check for this and call `trimHistory()` if the number calculated is less than zero.
 
 ```java
   private static final long MAX_HISTORY_TIME_MS = 30000L;
@@ -203,7 +203,7 @@ We simply check for this and call `trimHistory()` if the number calculated is le
       // The timer is already being handled
       return;
     }
-    
+
     final long timeUntilNextTrim = (this.history.firstKey() + MAX_HISTORY_TIME_MS) - System.currentTimeMillis();
     if (timeUntilNextTrim > 0) {
       // Set a timer for when the next record needs to be dropped
diff --git a/src/_backend/timers.md b/src/_java_backend/timers.md
similarity index 96%
rename from src/_backend/timers.md
rename to src/_java_backend/timers.md
index 253103c..dba655e 100644
--- a/src/_backend/timers.md
+++ b/src/_java_backend/timers.md
@@ -6,8 +6,8 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/timers
 redirect_from:
-  - /tutorials/timers/
-  - /reference/timers.html
+  - /java/tutorials/timers/
+  - /java/reference/timers.html
 ---
 
 The ability for a Swim server to repeatedly trigger custom actions at Agent-level whim is often a desired feature in a Swim application. Swim provides the means to set timers, which enable users to both define functions (called TimerFunctions) and trigger them at desired times.
diff --git a/src/_backend/traits.md b/src/_java_backend/traits.md
similarity index 90%
rename from src/_backend/traits.md
rename to src/_java_backend/traits.md
index 5f903dc..26c9d8a 100644
--- a/src/_backend/traits.md
+++ b/src/_java_backend/traits.md
@@ -6,18 +6,18 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/traits
 redirect_from:
-  - /tutorials/traits/
-  - /reference/traits.html
+  - /java/tutorials/traits/
+  - /java/reference/traits.html
 ---
 
-In the [Planes guide]({% link _backend/planes.md %}), we describe a distributed object model to facilitate shared context for a group of **Web Agents**. In this guide we describe the concept of **'Trait'** utilized for sharing of data across multiple **Web Agents.** 
+In the [Planes guide]({% link _java_backend/planes.md %}), we describe a distributed object model to facilitate shared context for a group of **Web Agents**. In this guide we describe the concept of **'Trait'** utilized for sharing of data across multiple **Web Agents.**
 
-There are two types of traits: 
+There are two types of traits:
 
 1. Static Traits
 2. Dynamic Traits
 
-For Static Traits, the agents are declared and defined upfront via configuration. On the other hand, Dynamic Traits follow the dynamic agent definition structure, so multiple agents can be created and run at runtime. This facilitates runtime polymorphism. 
+For Static Traits, the agents are declared and defined upfront via configuration. On the other hand, Dynamic Traits follow the dynamic agent definition structure, so multiple agents can be created and run at runtime. This facilitates runtime polymorphism.
 
 ### Traits
 
@@ -73,7 +73,7 @@ liquid: @fabric {
 // LiquidAgent.java, WaterAgent.java, JuiceAgent.java
 
   @SwimLane("sharedInfo")
-  ValueLane<String> sharedInfo;     
+  ValueLane<String> sharedInfo;
 ```
 
 ### Step 3: Set the Lane Data
diff --git a/src/_backend/value-lanes.md b/src/_java_backend/value-lanes.md
similarity index 93%
rename from src/_backend/value-lanes.md
rename to src/_java_backend/value-lanes.md
index 74700d0..b07ef64 100644
--- a/src/_backend/value-lanes.md
+++ b/src/_java_backend/value-lanes.md
@@ -6,17 +6,17 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/value_lanes
 redirect_from:
-  - /tutorials/value-lanes/
-  - /reference/value-lanes.html
+  - /java/tutorials/value-lanes/
+  - /java/reference/value-lanes.html
 ---
 
-In the [Web Agents guide]({% link _backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+In the [Web Agents guide]({% link _java_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
 
 Lanes come in many flavors, but every lane type exposes:
 
 - A **means to act** on this lane
 - Customizable **lifecycle callbacks** that execute during the runtime of this action
-- Various means to **strongly type** (i.e. *parametrize*) the lane
+- Various means to **strongly type** (i.e. _parametrize_) the lane
 - Universal WARP **subscriptions** to this lane
 
 A **value lane** stores a **scalar** value and still meets these requirements:
@@ -160,7 +160,7 @@ class CustomClient {
 
 There are two ways to read data from value lanes, both of which require opening a downlink.
 The simpler approach is to simply call `get()` on the downlink to read its value at the time of the invocation.
-The far more powerful approach uses the fact that value downlinks *also* have access to `didSet()`. This enables an event-driven style of programming where client programs are treated as completely in sync with the server. And, excluding network latency and backpressure regulation of network packets, they basically are.
+The far more powerful approach uses the fact that value downlinks _also_ have access to `didSet()`. This enables an event-driven style of programming where client programs are treated as completely in sync with the server. And, excluding network latency and backpressure regulation of network packets, they basically are.
 
 ```java
 // swim/basic/CustomClient.java
diff --git a/src/_backend/warp.md b/src/_java_backend/warp.md
similarity index 97%
rename from src/_backend/warp.md
rename to src/_java_backend/warp.md
index f1495a5..bcf2d73 100644
--- a/src/_backend/warp.md
+++ b/src/_java_backend/warp.md
@@ -5,8 +5,8 @@ description: "The protocol for multiplexing bidirectional streams between large
 group: Reference
 layout: documentation
 redirect_from:
-  - /concepts/warp/
-  - /reference/warp.html
+  - /java/concepts/warp/
+  - /java/reference/warp.html
 ---
 
 The internet routes packets between physical or virtual machines, identified by IP addresses. On top of the internet sits the World Wide Web you're using right now, which routes requests and responses for Web Resources, identified by URIs. The Web was built for documents. But treating everything like a document is quite limiting. A smart city isn't a document; it's a continuously evolving digital mirror of reality.
diff --git a/src/_backend/web-agents.md b/src/_java_backend/web-agents.md
similarity index 92%
rename from src/_backend/web-agents.md
rename to src/_java_backend/web-agents.md
index 17fc4e1..d0be315 100644
--- a/src/_backend/web-agents.md
+++ b/src/_java_backend/web-agents.md
@@ -6,11 +6,11 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/web_agents
 redirect_from:
-  - /tutorials/web-agents/
-  - /reference/web-agents.html
+  - /java/tutorials/web-agents/
+  - /java/reference/web-agents.html
 ---
 
-Swim servers utilize a general purpose distributed object model in which the objects are called **Web Agents**. 
+Swim servers utilize a general purpose distributed object model in which the objects are called **Web Agents**.
 Programming with this model feels like typical object-oriented programming with additional key innovations in addressability, statefulness, consistency, boundedness, and composability.
 
 Although this analogy holds very well for the most part, there are two important catches:
@@ -22,7 +22,7 @@ Don't worry if these points feel restrictive through this article; much finer co
 
 ### Declaration
 
-Just like with (instantiable) `class` declarations in Java, **Agent declarations** in Swim define the behavior for **instances** of those Agents. 
+Just like with (instantiable) `class` declarations in Java, **Agent declarations** in Swim define the behavior for **instances** of those Agents.
 Declarations alone don't actually instantiate anything.
 
 To declare a Web Agent, extend the `AbstractAgent` class from the `swim.api` module:
@@ -41,11 +41,11 @@ public class UnitAgent extends AbstractAgent {
 ### External Addressability
 
 Every Web Agent has a universal, logical address, in the form of a URI.
-The URI of a custom `PlanetAgent` might look something like `"/planet/Mercury"`. 
+The URI of a custom `PlanetAgent` might look something like `"/planet/Mercury"`.
 That of a singleton `SunAgent` might just look like `"/sun"`.
 By decoupling Web Agent's logical addresses from the network addresses of their host machines, Swim applications become invariant to the infrastructure on which they're deployed.
 
-Each Web Agent is aware of its own URI, available via its `nodeUri()` method. 
+Each Web Agent is aware of its own URI, available via its `nodeUri()` method.
 Let's add a simple utility method to each `UnitAgent` to help us identify the Agent from which a logged message originated.
 
 ```java
@@ -63,7 +63,7 @@ public class UnitAgent extends AbstractAgent {
 
 ### Instantiation
 
-For an Agent to know its **own** identifier is only half of the problem. 
+For an Agent to know its **own** identifier is only half of the problem.
 To address the other half, every Swim server runs a **plane** that manages the runtime of and provides a shared context for a group of Web Agents.
 
 One of a plane's many responsibilities is to resolve Agent URIs for requests.
@@ -80,11 +80,11 @@ basic: @fabric {
   # Notice usage of 'uri' keyword for a static component.
   @node {
     uri: "/unit/foo"
-    @agent(class: "swim.basic.UnitAgent") 
+    @agent(class: "swim.basic.UnitAgent")
   }
 
   # Dynamic Component
-  # Notice usage of 'pattern' keyword for a dynamic component. 
+  # Notice usage of 'pattern' keyword for a dynamic component.
   @node {
     pattern: "/unit/:id"
     @agent(class: "swim.basic.UnitAgent")
@@ -102,21 +102,21 @@ basic: @fabric {
 
 Statically defined agents (illustrated using 'uri' keyword) are automatically instantiated by the corresponding Swim Plane.
 
-A Dynamic Web Agent is only instantiated when its `nodeUri` is invoked for the first time. 
-With the code we have so far, we can instantiate any number of `UnitAgent`s by either defining them in the configuration file or by invoking URIs with the `"/unit/"` prefix. 
+A Dynamic Web Agent is only instantiated when its `nodeUri` is invoked for the first time.
+With the code we have so far, we can instantiate any number of `UnitAgent`s by either defining them in the configuration file or by invoking URIs with the `"/unit/"` prefix.
 For example, if we invoke `"/unit/1"`, `"/unit/foo"`, and `"/unit/foo_1"`, three `UnitAgent`s will be instantiated, one for each URI.
 
 {% include alert.html title='Caution' text='If you have multiple agent types within a plane, ensure that their URI patterns do not **clash**. This is a stricter requirement than saying that the patterns are <strong>identical</strong>; for example, <strong>"/unit/:id"</strong> and <strong>"/unit/:foo"</strong> clash. Suppose these same patterns annotated different agent types; how would a plane know which type of Agent to seek or instantiate for the request <strong>"/unit/1"</strong>?' %}
 
-In addition to the `nodeUri()` method mentioned in the previous section, every Agent also has access to a `Value getProp(String prop)` convenience method. 
-This returns a `swim.structure.Text` object containing the value of the dynamic `nodeUri` component with the name `prop`, `absent()` if it doesn't exist. 
+In addition to the `nodeUri()` method mentioned in the previous section, every Agent also has access to a `Value getProp(String prop)` convenience method.
+This returns a `swim.structure.Text` object containing the value of the dynamic `nodeUri` component with the name `prop`, `absent()` if it doesn't exist.
 For example, `getProp("id").stringValue()` will return either `"1"`, `"foo"`, or `"foo_1"`, depending on which of the above three agents we are currently running in. `getProp("foo")` will return `absent()`.
 
-Further reading: [Planes]({% link _backend/planes.md %})
+Further reading: [Planes]({% link _java_backend/planes.md %})
 
 ### Lifecycle Callbacks
 
-Recall that Web Agent methods are not directly invoked. 
+Recall that Web Agent methods are not directly invoked.
 Instead, the Swim runtime schedules and executes callbacks stages of an Agent's lifecycle. For the most part, you will only care about two:
 
 - `void didStart()`: executed once immediately after this Agent has started
diff --git a/src/_devguide/1-introduction.md b/src/_java_devguide/1-introduction.md
similarity index 89%
rename from src/_devguide/1-introduction.md
rename to src/_java_devguide/1-introduction.md
index 65cd153..3102d6a 100644
--- a/src/_devguide/1-introduction.md
+++ b/src/_java_devguide/1-introduction.md
@@ -5,8 +5,8 @@ description: "Introduction to the SwimOS developer guide."
 group: Introduction
 layout: documentation
 redirect_from:
-  - /developer-guide/introduction
-  - /developer-guide/introduction.html
+  - /java/developer-guide/introduction
+  - /java/developer-guide/introduction.html
 ---
 
 Welcome to the SwimOS developer's guide, an introductory guide to the SwimOS framework.
@@ -19,4 +19,4 @@ While we'll cover the 'how' of building streaming apps, if you're interested in
 # Who This Guide Is For
 
 This guide assumes that you've written code in Java before, as such we will not explain any Java specific features or syntax.
-We will focus on features of the SwimOS framework which by design aren't overly complex to use, although some background knowledge of software development technologies is required.
\ No newline at end of file
+We will focus on features of the SwimOS framework which by design aren't overly complex to use, although some background knowledge of software development technologies is required.
diff --git a/src/_devguide/2-getting-started.md b/src/_java_devguide/2-getting-started.md
similarity index 71%
rename from src/_devguide/2-getting-started.md
rename to src/_java_devguide/2-getting-started.md
index c59324a..4138dcc 100644
--- a/src/_devguide/2-getting-started.md
+++ b/src/_java_devguide/2-getting-started.md
@@ -5,9 +5,9 @@ description: "Getting Started using SwimOS."
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /developer-guide/getting-started
-  - /developer-guide/getting-started.html
+  - /java/developer-guide/getting-started
+  - /java/developer-guide/getting-started.html
 ---
 
 Let's get started on the SwimOS journey.
-In this chapter we will discuss project setup and create the most basic SwimOS 'Hello, world!' server and extend it to incorporate some SwimOS core concepts, agents and lanes.
\ No newline at end of file
+In this chapter we will discuss project setup and create the most basic SwimOS 'Hello, world!' server and extend it to incorporate some SwimOS core concepts, agents and lanes.
diff --git a/src/_devguide/2.1-swim-create.md b/src/_java_devguide/2.1-swim-create.md
similarity index 91%
rename from src/_devguide/2.1-swim-create.md
rename to src/_java_devguide/2.1-swim-create.md
index 2b400d3..dcec014 100644
--- a/src/_devguide/2.1-swim-create.md
+++ b/src/_java_devguide/2.1-swim-create.md
@@ -5,13 +5,13 @@ description: "Set up a blank SwimOS project with swim-create."
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /developer-guide/swim-create
-  - /developer-guide/swim-create.html
+  - /java/developer-guide/swim-create
+  - /java/developer-guide/swim-create.html
 ---
 
 To initiate the development of a SwimOS application, start by establishing the project in which your code will reside.
 
-For Linux users, SwimOS offers a convenient command-line tool that swiftly initializes an empty SwimOS project. 
+For Linux users, SwimOS offers a convenient command-line tool that swiftly initializes an empty SwimOS project.
 However, if you're using Windows, proceed to the next page for manual instructions on setting up your project.
 
 # The `swim-create` Tool
@@ -22,8 +22,8 @@ To install the `swim-create` tool simply run the following command:
 $ curl -L https://github.com/nstreamio/swim-create/releases/latest/download/swim-create-x86_64-unknown-linux-gnu.tar.gz | sudo tar -xz -C /usr/local/bin
 ```
 
-With the `swim-create` command at your disposal, go to the directory where you intend to create your SwimOS project. 
-Execute the `swim-create` command, specifying the desired name for your project/application. 
+With the `swim-create` command at your disposal, go to the directory where you intend to create your SwimOS project.
+Execute the `swim-create` command, specifying the desired name for your project/application.
 In this example, we've named it 'tutorial'.
 
 ```text
diff --git a/src/_devguide/2.2-project-setup.md b/src/_java_devguide/2.2-project-setup.md
similarity index 89%
rename from src/_devguide/2.2-project-setup.md
rename to src/_java_devguide/2.2-project-setup.md
index acd09ec..c6fcda2 100644
--- a/src/_devguide/2.2-project-setup.md
+++ b/src/_java_devguide/2.2-project-setup.md
@@ -5,18 +5,18 @@ description: "Set up a blank SwimOS project."
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /developer-guide/project-setup
-  - /developer-guide/project-setup.html
+  - /java/developer-guide/project-setup
+  - /java/developer-guide/project-setup.html
 ---
 
-_Note: This page is written specifically for Linux users. 
+_Note: This page is written specifically for Linux users.
 The commands may need to be tweaked for Windows users but the general steps should be the same._
 
 To initiate the setup of a SwimOS project, start by creating and navigating to the directory where it will be located.
 We will be using the `tutorial` directory with the same project name.
 
 Following this, we'll configure our build tool to streamline dependency management and facilitate seamless application execution.
-Typically, we opt for Gradle in our applications, and the basic setup will be covered in the upcoming section. 
+Typically, we opt for Gradle in our applications, and the basic setup will be covered in the upcoming section.
 If you prefer to use a different build tool, like Maven, feel free to do so, although the specifics are beyond the scope of this guide.
 
 # Gradle Setup
@@ -58,7 +58,7 @@ The repositories and dependencies sections in the file will enable us to incorpo
 
 # The `src` Directory
 
-With the build tool configured, let's proceed to establish the directory structure for the project source code. 
+With the build tool configured, let's proceed to establish the directory structure for the project source code.
 Create the necessary directories and construct the following tree within your project:
 
 ```
@@ -70,8 +70,9 @@ src
 ```
 
 Finally, create two blank files:
+
 - `MainPlane.java` in the `tutorial` directory (`src/main/java/tutorial/MainPlane.java`).
 - `server.recon` in the `resources` directory (`src/main/resources/server.recon`).
 
-On the upcoming page, we'll delve into the details of these empty files. 
-With this setup, our project is now ready for some code.
\ No newline at end of file
+On the upcoming page, we'll delve into the details of these empty files.
+With this setup, our project is now ready for some code.
diff --git a/src/_devguide/2.3-hello-world.md b/src/_java_devguide/2.3-hello-world.md
similarity index 97%
rename from src/_devguide/2.3-hello-world.md
rename to src/_java_devguide/2.3-hello-world.md
index 294ba24..06571bd 100644
--- a/src/_devguide/2.3-hello-world.md
+++ b/src/_java_devguide/2.3-hello-world.md
@@ -5,8 +5,8 @@ description: "Start the most basic SwimOS server."
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /developer-guide/hello-world
-  - /developer-guide/hello-world.html
+  - /java/developer-guide/hello-world
+  - /java/developer-guide/hello-world.html
 ---
 
 Now it's time to write some code and run the most basic SwimOS server.
@@ -14,7 +14,7 @@ Now it's time to write some code and run the most basic SwimOS server.
 # The `server.recon` File
 
 Assuming you've followed one of the two previous pages to set up your project, you should have at least a blank `server.recon` file in your project.
-This file serves as the primary configuration file for the SwimOS server. 
+This file serves as the primary configuration file for the SwimOS server.
 While it has the capacity to define various aspects, we'll focus on a few key elements for now, saving more intricate features for upcoming chapters.
 
 The file is written in Recon, think of it as Json with a few extra features that allow us to be a bit more expressive (mainly attributes, identifiable by the `@`).
@@ -27,7 +27,7 @@ _File: src/main/resources/server.recon_
 ```text
 tutorial: @fabric {
     @plane(class: "tutorial.MainPlane")
-    
+
 }
 
 @web(port: 9001) {
@@ -105,4 +105,4 @@ In summary, we have set up and configured a SwimOS server to run on a given port
 Then, using a lifecycle callback, we log a message once the plane has been created.
 
 It may not seem like much but this is a huge first step to building a SwimOS streaming application.
-With project and server setup out the way, we can continue this example on the next page, making use of SwimOS's fundamental building blocks, agents.
\ No newline at end of file
+With project and server setup out the way, we can continue this example on the next page, making use of SwimOS's fundamental building blocks, agents.
diff --git a/src/_devguide/2.4-hello-agent.md b/src/_java_devguide/2.4-hello-agent.md
similarity index 97%
rename from src/_devguide/2.4-hello-agent.md
rename to src/_java_devguide/2.4-hello-agent.md
index becac03..4d6c00f 100644
--- a/src/_devguide/2.4-hello-agent.md
+++ b/src/_java_devguide/2.4-hello-agent.md
@@ -5,11 +5,11 @@ description: "Instantiate some SwimOS Web Agents."
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /developer-guide/hello-agent
-  - /developer-guide/hello-agent.html
+  - /java/developer-guide/hello-agent
+  - /java/developer-guide/hello-agent.html
 ---
 
-Having completed the setup, we're ready to expand our tutorial application. 
+Having completed the setup, we're ready to expand our tutorial application.
 We'll now incorporate SwimOS's fundamental building blocks - agents.
 Agents will be thoroughly covered in a dedicated chapter.
 To help you start using agents, we'll bypass certain details until that chapter.
@@ -127,4 +127,4 @@ Running server...
 You can see that sending a message to a URI that matches the pattern we defined before causes an agent with that URI to be created.
 
 We haven't yet covered a lot of the features that make agents useful for building streaming applications, but we have already seen how easy they are to create.
-On the next page we will continue this example to add lanes to these agents.
\ No newline at end of file
+On the next page we will continue this example to add lanes to these agents.
diff --git a/src/_devguide/2.5-hello-lane.md b/src/_java_devguide/2.5-hello-lane.md
similarity index 94%
rename from src/_devguide/2.5-hello-lane.md
rename to src/_java_devguide/2.5-hello-lane.md
index a827f5a..2179775 100644
--- a/src/_devguide/2.5-hello-lane.md
+++ b/src/_java_devguide/2.5-hello-lane.md
@@ -5,11 +5,11 @@ description: "Open lanes on SwimOS Web Agents."
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /developer-guide/hello-lane
-  - /developer-guide/hello-lane.html
+  - /java/developer-guide/hello-lane
+  - /java/developer-guide/hello-lane.html
 ---
 
-Now that we've established several agents, the next step is to expose their state and provide a method for interacting with them. 
+Now that we've established several agents, the next step is to expose their state and provide a method for interacting with them.
 This is where lanes come into play.
 Lanes will be thoroughly covered in a dedicated chapter.
 To help you start using lanes, we'll bypass certain details until that chapter.
@@ -45,8 +45,8 @@ Breaking this down a bit:
 
 - The lane has a `String` parameter type, matching the type of payload it will receive.
 
-- We add an `onCommand` callback that logs the payload received. 
-_This is not a compulsory and lanes can be created with no callbacks attached._
+- We add an `onCommand` callback that logs the payload received.
+  _This is not a compulsory and lanes can be created with no callbacks attached._
 
 - We annotate the lane variable with `@SwimLane`, passing the lane URI of `mission` as an argument.
 
@@ -92,4 +92,4 @@ Initially, as observed previously, the agent didn't exist, prompting the initiat
 Subsequently, the `onCommand` callback on the `mission` lane is invoked, passing along the payload we provided.
 
 This is a great start to building streaming applications - agents and lanes are the core of SwimOS.
-In the upcoming chapters, we'll circle back to cover certain details we skipped over and introduce you to new features of agents and lanes.
\ No newline at end of file
+In the upcoming chapters, we'll circle back to cover certain details we skipped over and introduce you to new features of agents and lanes.
diff --git a/src/_devguide/index.md b/src/_java_devguide/index.md
similarity index 89%
rename from src/_devguide/index.md
rename to src/_java_devguide/index.md
index 6750ae1..46bcb4f 100644
--- a/src/_devguide/index.md
+++ b/src/_java_devguide/index.md
@@ -1,6 +1,6 @@
 ---
 title: Developer Guide
-permalink: /developer-guide/
+permalink: /java/developer-guide/
 layout: documentation
 description: "Developer Guide to SwimOS"
 toc: false
diff --git a/src/_java_tutorials/demos.md b/src/_java_tutorials/demos.md
new file mode 100644
index 0000000..72917b1
--- /dev/null
+++ b/src/_java_tutorials/demos.md
@@ -0,0 +1,47 @@
+---
+title: Demo Apps
+layout: documentation
+description: "Learn by example through demos, cookbooks, and sample code."
+group: Demos
+redirect_from:
+  - /java/meet/
+---
+
+## Build Apps with Ease
+
+Swim applications are comprised of stateful web agents, which represent real-world objects, and streamlets, bits of application logic which continuously analyze streaming inputs, update their own state, and stream output over their links to other streamlets or to users and applications. By combining web agents and streamlets, Swim developers can quickly model even the most complex real-world systems, processes and environments.
+
+## Example Apps
+
+To try Swim, check out an example application, like Ripple, Traffic, Transit. Or clone a [starter application](https://github.com/swimos/tutorial) on which to base a new app.
+
+### Ripple
+
+Ripple is a real-time synchronous shared multiplayer experience built on the Swim platform
+
+- [View a live demo](https://ripple.swim.inc/)
+- [Check it out on GitHub](https://github.com/swimos/ripple)
+- [Download a zip](https://github.com/swimos/ripple/archive/master.zip)
+
+### Traffic
+
+Traffic processes 30,000 data points per second from connected traffic intersections
+
+- [View a live demo](https://traffic.swim.inc/)
+- [Check it out on GitHub](https://github.com/swimos/traffic)
+- [Download a zip](https://github.com/swimos/traffic/archive/master.zip)
+
+### Transit
+
+Transit analyzes application performance to deliver continuous insights in real-time
+
+- [View a live demo](https://transit.swim.inc/)
+- [Check it out on GitHub](https://github.com/swimos/transit)
+- [Download a zip](https://github.com/swimos/transit/archive/master.zip)
+
+### Cookbooks
+
+Cookbook examples are real-world examples of SwimOS concepts in action.
+
+- [Check it out on GitHub](https://github.com/swimos/cookbook)
+- [Download a zip](https://github.com/swimos/cookbook/archive/refs/heads/master.zip)
diff --git a/src/_tutorials/index.md b/src/_java_tutorials/index.md
similarity index 88%
rename from src/_tutorials/index.md
rename to src/_java_tutorials/index.md
index 275ff96..4b9cbaf 100644
--- a/src/_tutorials/index.md
+++ b/src/_java_tutorials/index.md
@@ -2,8 +2,9 @@
 title: Tutorials
 layout: documentation
 toc: false
+permalink: /java/tutorials/
 redirect_from:
-  - /tutorials
+  - /java/tutorials/
 description: "Building streaming data applications doesn't have to be hard. Learn how to use SwimOS's stateful back-end & real time front-end to bring your data to life."
 ---
 
diff --git a/src/_tutorials/monitor.md b/src/_java_tutorials/monitor.md
similarity index 98%
rename from src/_tutorials/monitor.md
rename to src/_java_tutorials/monitor.md
index fd7dbe7..b85e20b 100644
--- a/src/_tutorials/monitor.md
+++ b/src/_java_tutorials/monitor.md
@@ -74,17 +74,16 @@ In <a href="https://github.com/swimos/tutorial-monitor/blob/main/server/src/main
   }
 ```
 
-
 ## Monitoring Server
 
 ### Machine Web Agent
 
 The information collected for monitoring can be broken into three categories:
+
 - system information for each machine (static)
 - usage information for each machine (dynamic)
 - process information for each process running on the machine (static and dynamic)
 
-
 When static information is set, the <a href="https://github.com/swimos/tutorial-monitor/blob/main/server/src/main/java/swim/monitor/agent/MachineAgent.java" target="_blank">`MachineAgent`</a> registers with the cluster using the following command:
 
 ```java
@@ -106,7 +105,7 @@ with the help of `StatusComputer.computeStatusFromUsage()`.
             this.status.set(StatusComputer.computeStatusFromUsage(this.status.get(), newValue));
           });
 
-  @SwimLane("status")		
+  @SwimLane("status")
   ValueLane<Value> status = this.<Value>valueLane()
           .willSet(StatusComputer::computeSeverityFromStatus)
           .didSet((newValue, oldValue) -> {
@@ -153,7 +152,7 @@ The <a href="https://github.com/swimos/tutorial-monitor/blob/main/server/src/mai
           });
 ```
 
-For an explanation of downlinking, see [`downlinks`]({% link _backend/downlinks.md %}). 
+For an explanation of downlinking, see [`downlinks`]({% link _java_backend/downlinks.md %}).
 The `machines` join value lane exposes the status of individual machines with respect to system information, usage information, and process information, so that any connected client can check detail status for any machine in the cluster.
 
 `ClusterAgent` also aggregates the status of all machines and reflects that in an aggregate status to reflect the health of the cluster. The status is exposed to interested clients through the `status` value lane, and history is stored for the last 200 values. Note that since `timestamp` is the key, the field is removed from the corresponding value:
@@ -168,6 +167,7 @@ The `machines` join value lane exposes the status of individual machines with re
             }
           });
 ```
+
 `ClusterAgent` has a `computeStatus()` method that updates the aggregate status as machine status updates stream in. We will cherry picks portions of `computeStatus()` that generate the aggregate value for memory usage:
 
 ```java
@@ -201,7 +201,7 @@ The `machines` join value lane exposes the status of individual machines with re
 
 ## Rendering Status Information
 
-Data can be rendered to an HTML page relatively simply. To illustrate that, we include an html file <a href="https://github.com/swimos/tutorial-monitor/blob/main/ui/index.html" target="_blank">`/ui/index.html`</a> that illustrates how this is done. Most of this is boilerplate for displaying a chart, but the application-specific bit is here: 
+Data can be rendered to an HTML page relatively simply. To illustrate that, we include an html file <a href="https://github.com/swimos/tutorial-monitor/blob/main/ui/index.html" target="_blank">`/ui/index.html`</a> that illustrates how this is done. Most of this is boilerplate for displaying a chart, but the application-specific bit is here:
 
 ```java
 const histogramLink = swim.downlinkMap()
diff --git a/src/_tutorials/transit.md b/src/_java_tutorials/transit.md
similarity index 100%
rename from src/_tutorials/transit.md
rename to src/_java_tutorials/transit.md
diff --git a/src/_posts/2024-02-05-munin.md b/src/_posts/2024-02-05-munin.md
index 3af4afa..b67163b 100644
--- a/src/_posts/2024-02-05-munin.md
+++ b/src/_posts/2024-02-05-munin.md
@@ -1,10 +1,11 @@
 # Reddit Bot Overview
 
-This blog post will explore the use of <a target="_blank" href="https://github.com/swimos/swimos-docs/blob/main/src/_backend/http-lanes.md">HTTP lanes</a> in <a target="_blank" href="https://github.com/swimos/munin">**munin**</a>, a streaming data application built on SwimOS. **munin** is a real-time application that assigns answers to every submission on <a target="_blank" href="https://www.reddit.com/r/whatsthisbird/">r/WhatsThisBird</a> based on comments. It analyzes most comments internally but also makes external API calls (to eBird.org) for some. The application pushes every derived answer to a PostgreSQL database and interacts with Reddit by posting comments on submissions to display the ongoing analysis.
+This blog post will explore the use of <a target="_blank" href="https://github.com/swimos/swimos-docs/blob/main/src/_java_backend/http-lanes.md">HTTP lanes</a> in <a target="_blank" href="https://github.com/swimos/munin">**munin**</a>, a streaming data application built on SwimOS. **munin** is a real-time application that assigns answers to every submission on <a target="_blank" href="https://www.reddit.com/r/whatsthisbird/">r/WhatsThisBird</a> based on comments. It analyzes most comments internally but also makes external API calls (to eBird.org) for some. The application pushes every derived answer to a PostgreSQL database and interacts with Reddit by posting comments on submissions to display the ongoing analysis.
 
 ## Key Functionalities of **munin**
 
 1. **Real-time Categorization of Submissions:**
+
    - **munin** categorizes r/WhatsThisBird submissions into answered, unanswered, reviewed, and unreviewed, based on the analysis of comments.
    - The categorization is accessible through HTTP lanes and Swim-cli commands, providing detailed insights into each submission.
 
@@ -21,21 +22,25 @@ A design goal of **munin** is to provide a clean separation of concerns and make
 ## <a target="_blank" href="https://github.com/swimos/munin">**munin**</a> Web Agents at a Glance
 
 1. <a target="_blank" href="https://github.com/swimos/munin/blob/main/src/main/java/filethesebirds/munin/swim/SubmissionsAgent.java">**`SubmissionsAgent` (Manager of Submissions)**</a>:
+
    - Acts as an overarching manager for all active subreddit submissions.
    - Categorizes submissions, tracks their status, and manages their lifecycle.
    - Provides HTTP endpoints for external access to submission data, facilitating broader application integration.
 
 2. <a target="_blank" href="https://github.com/swimos/munin/blob/main/src/main/java/filethesebirds/munin/swim/SubmissionAgent.java">**`SubmissionAgent` (Individual Submission Handler)**</a>:
+
    - Each instance manages a specific submission.
    - Tracks detailed information about the submission, including status changes and associated comments.
    - Can be dynamically instantiated as needed, allowing efficient handling of multiple submissions concurrently.
 
 3. <a target="_blank" href="https://github.com/swimos/munin/blob/main/src/main/java/filethesebirds/munin/swim/PublishingAgent.java">**`PublishingAgent` (Comment Interaction Specialist)**</a>:
+
    - Manages the creation, updating, and deletion of comments on submissions.
    - Handles comment-related interactions in response to changes in the submission's state.
    - Efficiently manages Reddit API constraints through a queuing system.
 
 4. <a target="_blank" href="https://github.com/swimos/munin/blob/main/src/main/java/filethesebirds/munin/swim/CommentsFetchAgent.java">**`CommentsFetchAgent` (Comment Fetcher and Router)**</a>:
+
    - Fetches new comments and routes them to the relevant `SubmissionAgent`.
    - Filters comments based on submission status (e.g., shelving expired submissions).
    - Operates periodically, ensuring the system is up-to-date with the latest comments.
@@ -48,7 +53,7 @@ A design goal of **munin** is to provide a clean separation of concerns and make
 
 ## Serving SwimOS Streams as Plain REST Data
 
-Serving real-time SwimOS streams as plain REST data is simple and straightforward. In SwimOS, an <a target="_blank" href="https://github.com/swimos/swimos-docs/blob/main/src/_backend/http-lanes.md">HttpLane</a> is a type of lane that can respond to HTTP requests. This is analogous to a REST endpoint in a traditional web service framework. HTTP lanes are simple and integrate seamlessly with the real-time data handling capabilities of SwimOS. In <a target="_blank" href="https://github.com/swimos/munin">**munin**</a>, four such lanes are utilized:
+Serving real-time SwimOS streams as plain REST data is simple and straightforward. In SwimOS, an <a target="_blank" href="https://github.com/swimos/swimos-docs/blob/main/src/_java_backend/http-lanes.md">HttpLane</a> is a type of lane that can respond to HTTP requests. This is analogous to a REST endpoint in a traditional web service framework. HTTP lanes are simple and integrate seamlessly with the real-time data handling capabilities of SwimOS. In <a target="_blank" href="https://github.com/swimos/munin">**munin**</a>, four such lanes are utilized:
 
 - https://munin.swim.services/submissions?lane=api/answered
 - https://munin.swim.services/submissions?lane=api/unanswered
@@ -109,7 +114,6 @@ In the SubmissionsAgent, the call to `unansweredApiDoRespond` is delegated to `S
 - The method `unansweredApiDoRespond` is defined to handle HTTP requests specifically aimed at fetching data about unanswered submissions.
 - When an HTTP request is received, this method delegates the processing of the request to `SubmissionsAgentLogic.unansweredApiDoRespond`.
 
-
 ```
   HttpResponse<?> unansweredApiDoRespond(HttpRequest<Value> request) {
     return SubmissionsAgentLogic.unansweredApiDoRespond(this, request);
@@ -119,6 +123,7 @@ In the SubmissionsAgent, the call to `unansweredApiDoRespond` is delegated to `S
 As for the SubmissionsAgentLogic implementation, it performs the following tasks:
 
 1. **HTTP Response Creation (`unansweredApiDoRespond`)**:
+
    - This static method takes the `SubmissionsAgent` instance and the HTTP request as parameters.
    - It creates an `HttpResponse` object with a status of `HttpStatus.OK`, indicating a successful request.
    - The body of the response is generated by calling the `body` method, which formats the content as HTML.
@@ -136,7 +141,7 @@ Here's the code:
     return HttpResponse.create(HttpStatus.OK)
         .body(body(UNANSWERED_PAGE_FMT, runtime.unanswered.keySet()), MediaType.textHtml());
   }
-  
+
   private static String body(String fmt, Set<Long> ids) {
     final Iterator<Long> itr = ids.iterator();
     String oneLink = oneLink(itr, 1);
@@ -145,7 +150,7 @@ Here's the code:
       links.append(oneLink);
     }
     return String.format(fmt, links.toString());
-  }  
+  }
 ```
 
 `SubmissionsAgent` is passed in so that its `unanswered` lane can be accessed using `keySet()` which is exposed by all MapLanes.
diff --git a/src/_rust_backend/agent-design.md b/src/_rust_backend/agent-design.md
new file mode 100644
index 0000000..cf9d587
--- /dev/null
+++ b/src/_rust_backend/agent-design.md
@@ -0,0 +1,71 @@
+---
+title: Web Agent Design
+short-title: Web Agent Design
+group: Getting Started
+description: "How to model entities into nodes and agents"
+layout: documentation
+redirect_from:
+  - /rust/concepts/agent-design.html
+---
+
+Swim provides a framework to model business entities using distributed objects, the objects being **Web Agents**.
+An early design decision that arises is how to distribute these objects and what should be configured as a node or an agent.
+In this guide we will discuss some best practices and ideas for designing and modelling entities.
+
+## Entity Modeling
+
+**Entities** are identifiable domain elements and Swim **nodes** are addressable groupings of stateful agents which perform some logic.
+Comparing the two definitions, we get a pretty good idea of how to map our entities to nodes, (almost) one-to-one.
+
+Anything **uniquely addressable** can be mapped to a node.
+This can be singleton such as a node representing the whole system (`/system`), some entity type with a globally unique id (`/vehicle/:id`), or entities where some composite unique address can be constructed (`/building/:buildingId/room/:roomId`, since `roomId` is only unique to each building).
+
+As nodes are composed of one or more agents, that **have state** and **perform logic**, it follows that entities that don't have any or much behavior need not be a node.
+For example, lights in a room may be uniquely addressable however, if they are simply a boolean value of on or off, it may be cleaner to roll them up into a lane of the parent room node.
+
+Links and by extension join lanes can be used to connect agents and therefore model **entity relationships**.
+Any **groupings or aggregations** of entities can also be considered for nodes themselves, allowing aggregate statistics (counts, averages, deviations) to be calculated across the group.
+
+One final consideration is **resource management**; nodes execute in parallel and so to make use of multicore processing and maximize **parallelization**, it is desirable to split out monolithic entities into several nodes and agents.
+While nodes and agents are lightweight, they do have some **memory overhead**, therefore when scaling to millions of entities it may be more efficient to include small entities as lanes of their parent entities.
+
+**Database comparison**:
+We can draw similarities to relational database design when modelling entities with Swim.
+Table definitions map to web agent definitions, each row in the table being and instance of the web agent.
+Web agent lanes store values and fields so are the columns.
+Finally, the relationships between the tables (foreign keys) can be mirrored using links.
+
+**Examples:**
+
+- **100s of agencies with 1000s of vehicles each**: Create a node for each vehicle (entity agent) which join an agency node (aggregate agent).
+
+- **1000s of users with 1-5 addresses each**: Create a node for each user (entity agent), store the addresses in lanes of the user agents.
+  Addresses don't have any behaviour or logic, hence don't need an agent of their own.
+
+- **100k devices with 100s of sensors each**: Create a node for each device (entity agent), store values of sensors in lanes of the device agents.
+  We store the sensors in lanes to avoid creating millions of nodes and therefore a large memory footprint - if each sensor requires modelling explicitly then it may warrant a node per sensor.
+
+### URIs
+
+To avoid clashes and make clear what entity type each node is representing we recommend including the entity type in the node URI.
+
+For example, a vehicle with a unique ID should have URI `/vehicle/:id`.
+This also extends to composite URIs and a room with an ID unique to a building should have URI `/building/:buildingID/room/:roomId` - the `/room/` part helps avoid clashes if the building were to have other children such as doors.
+
+## Web Agent Granularity
+
+Now we have our nodes and entity model it is time to populate the nodes with agents to perform some logic and add behavior.
+
+In object-oriented programming it is often preferable to compose classes out of smaller **reusable** component classes; this is similar to composing nodes out of agents.
+Agents should favor being smaller and re-usable instead of large and monolithic.
+
+**Composability** is made easy with Swim as all agents within a node have access to all lanes and their lifecycle callbacks, this means there is no need to delegate calls to the correct agent with forwarding methods.
+
+One possible way to identify if an agent can be split into multiple is to see if there is a set of fields and methods that are tightly coupled, these can be separated into a new agent - remember that the new agent will still have access to the same lanes.
+
+A good example of an independent re-usable agent would be a 'geographic point agent', this is an agent that extracts longitude and latitude, performs any geospatial processing and exposes a lane to be used by some map UI.
+This agent could then be added to any node with a longitude and latitude to be rendered on the UI as well.
+
+The Nstream [**patch**](https://www.nstream.io/docs/backend/agent-relationship/) system provides multiple examples of re-usable agents that can be used to compose nodes.
+
+_Note: Keep in mind that as with objects in Java, each agent created will have a small memory overhead._
diff --git a/src/_rust_backend/aggregations.md b/src/_rust_backend/aggregations.md
new file mode 100644
index 0000000..73e542d
--- /dev/null
+++ b/src/_rust_backend/aggregations.md
@@ -0,0 +1,318 @@
+---
+title: Group and Aggregate Agents
+short-title: Agent Groups
+description: "How to group agents and calculate aggregate stats"
+cookbook: https://github.com/swimos/cookbook/tree/master/aggregations
+group: Swim Apps
+layout: documentation
+redirect_from:
+  - /rust/guides/aggregations.html
+---
+
+It is common to want to group agents together and calculate some aggregate stats across that set of agents.
+
+This pattern can really be extended to any kind of grouping where the members share some property, but some specific examples include:
+
+- Grouping vehicles by city
+- Grouping products by manufacturer
+- Grouping users by role
+- Grouping orders by customer
+
+Throughout this guide, for demonstration, we are going to build out the vehicle example, grouping the vehicles by the state (in the USA) they are currently in.
+
+Let's take a simple vehicle agent as a starting point, the main component of which is a [`ValueLane`]({% link _rust_backend/value-lanes.md %}) that stores the vehicle's status.
+
+```java
+public class VehicleAgent extends AbstractAgent {
+
+  @SwimLane("addEvent")
+  public CommandLane<Value> addEvent = this.<Value>commandLane()
+      .onCommand(v -> this.status.set(v));
+
+  @SwimLane("status")
+  public ValueLane<Value> status = this.<Value>valueLane();
+
+}
+```
+
+In this example the status of a vehicle is stored as a Swim `Value` but this can be changed to any supported type.
+
+### Group Agent
+
+First we are going to construct a simple group/aggregate agent, in our example a `StateAgent`.
+
+A [`JoinValueLane`]({% link _rust_backend/join-value-lanes.md %}) inside the `StateAgent` will become a map, the key being some unique identifier of a vehicle, and the value being the vehicle's current status.
+The lane will keep itself up to date with the `status` of the vehicle through the use of [`downlinks`]({% link _rust_backend/downlinks.md %}).
+
+```java
+public class StateAgent extends AbstractAgent {
+
+  @SwimLane("vehicles")
+  public JoinValueLane<Uri, Value> vehicles = this.<Uri, Value>joinValueLane();
+
+}
+```
+
+Notice the type parameters of the lane in the above example.
+
+- The first parameter is the type of the unique identifier of the vehicle.
+  As a node URI is unique to each agent we will be using that (but this could be anything else unique to the vehicle, e.g. `id: String`).
+- The second parameter is the type of the value to be downlinked, this should match the type of the `status` `ValueLane` in the vehicle agent.
+
+Now we need some way for a vehicle to register itself with the state and join the lane.
+To do this we open a [`CommandLane`]({% link _rust_backend/command-lanes.md %}) named `addVehicle` accepting a `Uri` - which will be the vehicle's node URI.
+The `downlink(K key)` method on the join value lane creates a downlink with the given unique key.
+We also specify the `nodeUri` and `laneUri` then start the downlink with `open()`.
+
+```java
+  @SwimLane("addVehicle")
+  public CommandLane<Uri> addVehicle = this.<Uri>commandLane()
+      .onCommand(v ->
+          this.vehicles
+              .downlink(v)
+              .nodeUri(v)
+              .laneUri("status")
+              .open());
+```
+
+We now have a working `StateAgent` that can accept a vehicle's node URI and will keep an up to date map of all registered vehicle's `status` lanes.
+
+See this in an agent in the [example](https://github.com/swimos/cookbook/blob/master/aggregations/src/main/java/swim/aggregations/StateAgent.java).
+
+### Joining
+
+Next we need to add some logic to the `VehicleAgent` to command the `StateAgent`'s `addVehicle` lane we created in the previous section.
+
+Assuming the URI pattern for state agents is `/state/:name` then we can create a `joinState` method in the `VehicleAgent`.
+The method will accept a state's name and then command the state's `addVehicle` lane with the vehicle's node URI.
+
+```java
+  private void joinState(final String state) {
+    command(
+        "/state/" + state,
+        "addVehicle",
+        Uri.form().mold(nodeUri()).toValue()
+    );
+  }
+```
+
+_Note: We have to convert the vehicle's node URI to a `Value` to send it via a command. For more information on this see [Forms]({% link _rust_backend/forms.md %})._
+
+We now need to call the above method, exactly when you will want to do this will depend on the use case.
+The most common cases are:
+
+- **Agent Start**: Call within the agent's `didStart()` lifecycle callback to join immediately on agent start.
+  The value ('state' in this example) can be static or loaded from a property of some kind.
+- **On Event**: Call from a lane's callback functions, this will allow the agent to join the group agent when some condition is met.
+
+Both approaches have a similar implementation, but we will show both.
+
+#### Agent Start
+
+We simply call `joinState` in the agent's `didStart()` lifecycle callback.
+
+```java
+  @Override
+  public void didStart() {
+    joinState("California");
+  }
+```
+
+This will join the `/state/California` `StateAgent` on start up and any updates to the vehicle's `status` lane will be reflected in the `vehicles` lane of the California state agent.
+
+See this in an agent in the [example](https://github.com/swimos/cookbook/blob/master/aggregations/src/main/java/swim/aggregations/StationaryVehicleAgent.java).
+
+#### On Event
+
+We add a `didSet` callback to the `status` lane of the `VehicleAgent`, extracting the `state` field from the new status and passing it to the `joinState` method - if the `state` field is not present then pass `null`.
+
+```java
+  @SwimLane("status")
+  public ValueLane<Value> status = this.<Value>valueLane()
+      .didSet((nv, ov) -> joinState(nv.get("state").stringValue(null)));
+```
+
+This introduces a problem; whenever the vehicle `status` is updated, the vehicle will try to join the state, even if it already has.
+Ideally we only want the vehicle to try to join if the `state` field in the `status` lane changes.
+We do this by keeping track of the state agent that the vehicle is currently joined and modifying `joinState` to only command if the state has changed.
+
+```java
+  private String currentState;
+
+  private void joinState(final String state) {
+    if (isSameAsCurrentState(state)) {
+      // If the new state is the same as the current state, then do nothing
+      return;
+    }
+    if (state != null) {
+      command(
+          "/state/" + state,
+          "addVehicle",
+          Uri.form().mold(nodeUri()).toValue()
+      );
+    }
+    this.currentState = state;
+  }
+
+  private boolean isSameAsCurrentState(final String state) {
+    return (this.currentState == null && state == null) ||
+        (this.currentState != null && this.currentState.equals(state));
+  }
+```
+
+We now have a `VehicleAgent` that will join any `StateAgent` when the vehicle moves into it.
+
+_Note: You may have noticed that if the vehicle moves between states, then it will be joined to multiple `StateAgent`s - we will address this in the next section._
+
+See this in an agent in the [example](https://github.com/swimos/cookbook/blob/master/aggregations/src/main/java/swim/aggregations/VehicleAgent.java).
+
+### Leaving
+
+Currently, vehicles join a new `StateAgent` whenever their status changes state, however, they do not leave the old one.
+We can fix this by implementing a way for the vehicles to leave or deregister from a state.
+
+Much like the `addVehicle` lane on the `StateAgent`, we can add a `removeVehicle` lane.
+This, when commanded with a vehicle's node URI, will remove it from the join lane and stop the downlink associated with it.
+
+```java
+  @SwimLane("removeVehicle")
+  public CommandLane<Uri> removeVehicle = this.<Uri>commandLane()
+      .onCommand(v ->
+          this.vehicles
+              .remove(v));
+```
+
+Next, in the `VehicleAgent` we can command this lane right before we join a new state (in the `joinState` method).
+
+```java
+  private void joinState(final String state) {
+    if (isSameAsCurrentState(state)) {
+      // If the new state is the same as the current state, then do nothing
+      return;
+    }
+
+    if (this.currentState != null) {
+      command("/state/" + this.currentState,
+          "removeVehicle",
+          Uri.form().mold(nodeUri()).toValue()
+      );
+    }
+
+    if (state != null) {
+      command(
+          "/state/" + state,
+          "addVehicle",
+          Uri.form().mold(nodeUri()).toValue()
+      );
+    }
+
+    this.currentState = state;
+  }
+```
+
+We now have a `VehicleAgent` that can move between `StateAgent`s whenever the `state` field in the `status` lane changes.
+
+See this in an agent in the [example](https://github.com/swimos/cookbook/blob/master/aggregations/src/main/java/swim/aggregations/VehicleAgent.java).
+
+### Aggregating
+
+Now we have an automatically updating, streaming map, we can continuously compute some metrics across the whole group.
+We can aggregate the status of all the vehicle agents into a status of the whole state.
+
+Working entirely inside the `StateAgent` from now on, we add a few things:
+
+- A `ValueLane` named `status` we can use to hold the status of the state.
+- A method `computeStatus()` that will be used to compute and set the state's status.
+- A `didUpdate` callback to the `vehicles` lane that calls `computeStatus()`.
+
+```java
+  @SwimLane("vehicles")
+  public JoinValueLane<Uri, Value> vehicles = this.<Uri, Value>joinValueLane()
+      .didUpdate((k, nv, ov) -> computeStatus());
+
+  @SwimLane("status")
+  public ValueLane<Value> status = this.<Value>valueLane();
+
+  private void computeStatus() {
+    /// Compute and set the state's status
+  }
+```
+
+Whenever a vehicle's `status` changes, the `status` of the state will be recomputed.
+
+All that's left to do now is decide on the content of the state's status.
+There are a various computations we can do to create an aggregated status, but we will show a few of the most common.
+
+Each one is in the [example](https://github.com/swimos/cookbook/blob/master/aggregations/src/main/java/swim/aggregations/VehicleAgent.java).
+
+#### Count
+
+Getting a count of all vehicles in the state is the same as getting the size of the join value lane which can be done with the `size()` method on the lane.
+For any other count, for example, a count of vehicles currently moving, we can loop through the map, keeping a counter of all vehicles that meet this condition.
+
+```java
+  private void computeStatus() {
+
+    int movingVehicles = 0;
+    for (final Uri vehicleUri : this.vehicles.keySet()) {
+      if (this.vehicles.get(vehicleUri).get("isMoving").booleanValue(false)) {
+        movingVehicles++;
+      }
+    }
+
+    this.status.set(
+        Record.create(2)
+            .slot("vehicle_count", this.vehicles.size())
+            .slot("moving_vehicle_count", movingVehicles)
+    );
+  }
+```
+
+#### Mean
+
+Calculating a mean is done by looping through all the entries of the join value lane, keeping a total and dividing by the count at the end.
+
+```java
+  private void computeStatus() {
+
+    int totalSpeed = 0, movingVehicles = 0;
+
+    for (final Uri vehicleUri : this.vehicles.keySet()) {
+      totalSpeed += this.vehicles.get(vehicleUri).get("speed").intValue(0);
+
+      if (this.vehicles.get(vehicleUri).get("isMoving").booleanValue(false)) {
+        movingVehicles++;
+      }
+    }
+
+    this.status.set(
+        Record.create(2)
+          .slot("mean_speed", this.vehicles.size() == 0 ? 0 : totalSpeed / this.vehicles.size())
+          .slot("mean_speed_of_moving_vehicles", movingVehicles == 0 ? 0 : totalSpeed / movingVehicles)
+    );
+  }
+```
+
+Here we calculate the `mean_speed` across all vehicles and the `mean_speed_of_moving_vehicles` across a subset of the vehicles.
+
+#### Max/Min
+
+Finding the max or min of some value across all the entries in the join lane can be done by looping through the entries and keeping track of the max/min.
+
+```java
+  private void computeStatus() {
+
+    int topSpeed = 0;
+    for (final Uri vehicleUri : this.vehicles.keySet()) {
+      int currentVehiclesSpeed = this.vehicles.get(vehicleUri).get("speed").intValue(0);
+      if (currentVehiclesSpeed > topSpeed) {
+        topSpeed = currentVehiclesSpeed;
+      }
+    }
+
+    this.status.set(
+        Record.create(1)
+          .slot("top_speed", topSpeed)
+    );
+  }
+```
diff --git a/src/_rust_backend/cli.md b/src/_rust_backend/cli.md
new file mode 100644
index 0000000..8b7f6f3
--- /dev/null
+++ b/src/_rust_backend/cli.md
@@ -0,0 +1,113 @@
+---
+title: Stream Data Using the swim-cli
+short-title: Swim CLI
+description: "How to stream or fetch data from a Swim application using the swim-cli"
+group: Utilities
+layout: documentation
+redirect_from:
+  - /rust/guides/cli.html
+---
+
+The [**swim-cli**](https://www.npmjs.com/package/@swim/cli) is the simplest way to fetch or stream data from a Swim application.
+All types of lanes can be streamed to the command line and so the **swim-cli** can be useful for validation.
+
+Feel free to use our endpoint for checking:
+
+- host: `warps://cellular.swim.services`
+- node: `/country/US/state/CA`
+- lane (Value): `status`
+- lane (Map): `alerts`
+
+_Note: The host uri uses the `warps` protocol, this is because the server uses secure websockets (TLS). For any servers using non-secure websockets (TLS not enabled) then `warp` must be used._
+
+### Installation
+
+You must have `npm` to install the Swim command line interface. To install the [swim-cli](https://www.npmjs.com/package/@swim/cli) globally:
+
+```bash
+npm install -g @swim/cli
+```
+
+### Stream from a Lane
+
+The **link** and **sync** commands can both be used to stream data from Swim lanes.
+Both commands will stream any updates to a lane however **sync** will first fetch the current value of the lane.
+The commands have the following format:
+
+```bash
+swim-cli link -h {hostUri} -n {nodeUri} -l {laneUri}
+swim-cli sync -h {hostUri} -n {nodeUri} -l {laneUri}
+```
+
+Notice the `-h`, `-n`, `-l` options are for the URI of `host`, `node`, and `lane` respectively.
+Substituting in the details of the test endpoint above:
+
+```bash
+swim-cli link -h warps://cellular.swim.services -n /country/US/state/CA -l status
+swim-cli sync -h warps://cellular.swim.services -n /country/US/state/CA -l status
+```
+
+These commands will both stream any updates to the `status` lane of the `/country/US/state/CA` node, however **sync** first gets the current value of the lane.
+(Try them yourself)
+
+_Note: The difference between sync and link becomes more obvious when streaming a map lane - see next section._
+
+The **link** and **sync** commands will continue to stream data until the command is terminated with `CTRL + C`.
+
+#### Value vs Map
+
+When streaming from a Swim **value** lane (as the above examples), you will notice that just the value of the lane is output.
+Example output from **value** lane:
+
+```
+{siteCount:1193,warnCount:115,alertCount:10}
+```
+
+When streaming a **map** lane, we only send the new value of the entry that has been updated.
+This means the output of the stream must now include the key of the entry being updated (or removed).
+We can stream a **map** lane (`alerts`) as an example:
+
+```bash
+swim-cli link -h warps://cellular.swim.services -n /country/US/state/CA -l alerts
+```
+
+Output:
+
+```
+@update(key:"/site/15550"){coordinates:{-122.308114,40.442505},severity:1.2732812701071294}
+@remove(key:"/site/20641")
+@update(key:"/site/779"){coordinates:{-120.045813,38.802205},severity:1.0512594070918895}
+```
+
+You will notice the presence of `@update` and `@remove` both referencing the key of the value being updated/removed.
+(Try it yourself)
+
+### Fetch from a Lane
+
+The **get** command will fetch the current value of the lane. The command has the following format:
+
+```bash
+swim-cli get -h {hostUri} -n {nodeUri} -l {laneUri}
+```
+
+Notice the `-h`, `-n`, `-l` options are for the URI of `host`, `node`, and `lane` respectively. Substituting in the details of the test endpoint above:
+
+```bash
+swim-cli get -h warps://cellular.swim.services -n /country/US/state/CA -l status
+```
+
+This will return the current value of the `status` lane of the `/country/US/state/CA` node.
+(Try it yourself)
+
+The **get** command terminates after fetching the current value.
+
+### Formatting Output (JSON)
+
+All of the above commands by default return output in a **recon** format.
+The `-f` option can be used to specify you would like to receive the output in a **json**.
+
+```bash
+swim-cli link -h warps://cellular.swim.services -n /country/US/state/CA -l status -f json
+```
+
+(Try it yourself)
diff --git a/src/_backend/command-lanes.md b/src/_rust_backend/command-lanes.md
similarity index 96%
rename from src/_backend/command-lanes.md
rename to src/_rust_backend/command-lanes.md
index d13bf25..f0b622f 100644
--- a/src/_backend/command-lanes.md
+++ b/src/_rust_backend/command-lanes.md
@@ -6,11 +6,11 @@ group: Reference
 layout: documentation
 cookbook: https://github.com/swimos/cookbook/tree/master/command_lanes
 redirect_from:
-  - /tutorials/command-lanes/
-  - /reference/command-lanes.html
+  - /rust/tutorials/command-lanes/
+  - /rust/reference/command-lanes.html
 ---
 
-In the [Web Agents guide]({% link _backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+In the [Web Agents guide]({% link _rust_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
 
 Lanes come in many flavors, but every lane type exposes:
 
@@ -18,7 +18,7 @@ Lanes come in many flavors, but every lane type exposes:
 - Customizable **lifecycle callbacks** that execute during the runtime of this action
 - Various means to **strongly type** (i.e. **parametrize**) the lane
 - Universal WARP **subscriptions** to this lane
-  
+
 A **command lane** is the simplest type of lane, that meets the following requirements:
 
 - Every command lane can be **commanded** with a message
@@ -55,7 +55,6 @@ Internally, lanes are always backed by `swim.structure.Value`s, regardless of th
 
 The `AbstractAgent` class comes with utility methods to construct lanes and make them accessible by the Swim runtime. Recall, however, that developers rarely instantiate Web Agents by explicitly invoking their constructors. The recommended pattern for adding a command lane to an Agent is to:
 
-
 - Exclude constructors entirely from Web Agents
 - Use the `commandLane()` method to instantiate the lane; note that this is a parametrized method
 - Through a builder pattern, override the lane's `void onCommand(V value)` method
@@ -166,7 +165,7 @@ class CustomClient {
 
 {% include alert.html title='Caution' text='If you have multiple lanes within an Agent type, ensure that their laneUris are not identical. Suppose we declare two different command lanes within our <strong>UnitAgent</strong> with laneUri <strong>"takeAction"</strong>; how would the Swim runtime know which one to message? That said, reusing laneUris <strong>across</strong> Agent types is perfectly acceptable, as requests corresponding to these are guaranteed to have different nodeUris.' %}
 
-Note that the `command()` signature only allows for `swim.structure.Value` payloads. Lanes internally use *forms* to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types, provided that a form for that data type exists. Even a custom Java class can be a lane type, provided that a form for that class exists. We will further discuss this topic in a more advanced cookbook.
+Note that the `command()` signature only allows for `swim.structure.Value` payloads. Lanes internally use _forms_ to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types, provided that a form for that data type exists. Even a custom Java class can be a lane type, provided that a form for that class exists. We will further discuss this topic in a more advanced cookbook.
 
 <!--Further reading: <a href="/reference/universal-addressability">Universal Addressability</a>, <a href="/reference/planes">Planes</a> <a href="/reference/structures">Structures</a>
 -->
@@ -215,7 +214,7 @@ class CustomClient {
 }
 ```
 
-Further reading: [Downlinks]({% link _backend/downlinks.md %})
+Further reading: [Downlinks]({% link _rust_backend/downlinks.md %})
 
 ## Try It Yourself
 
diff --git a/src/_rust_backend/demand-map-lanes.md b/src/_rust_backend/demand-map-lanes.md
new file mode 100644
index 0000000..7f0f6f9
--- /dev/null
+++ b/src/_rust_backend/demand-map-lanes.md
@@ -0,0 +1,202 @@
+---
+title: Demand Map Lanes
+short-title: Demand Map Lanes
+description: "Define persistent collection properties of Web Agents, and lazily generate events on state changes."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/demand_map_lanes
+redirect_from:
+  - /rust/tutorials/demand-map-lanes/
+  - /rust/reference/demand-map-lanes.html
+---
+
+In the [Web Agents guide]({% link _rust_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+
+Lanes come in many flavors, but every lane type exposes:
+
+- A **means to act** on this lane
+- Customizable **lifecycle callbacks** that execute during the runtime of this action
+- Various means to **strongly type** (i.e. _parametrize_) the lane
+- Universal WARP **subscriptions** to this lane
+
+A **demand map lane** does not store a collection, instead they are backed by a [map lane]({% link _rust_backend/map-lanes.md %}) and retrieve values purely on demand. Demand map lanes **lazily** generate events for the map lane, only when there is an uplink ready to receive the event. The lane meets these requirements:
+
+- Every demand map lane can be **cue(key)**-ed, signalling there is an event to be sent, for given key, to the uplinks, if ready. This is done in the map lane's `didUpdate()` method
+- Doing so will trigger its **onCue(key)** callback
+- The parameters on a demand map lane indicate the types of its keys and values it fetches
+- Demand map lane state and lifecycle can be subscribed to via both **map downlinks** and general-purpose **event downlinks**
+
+Demand map lanes can be cue()-ed at extremely high rates, and only as many events will be generated as each uplink can handle; the rate of event generation is tailored per uplink.
+
+Demand map lanes are ideal for publishing statistical events, where it isn't important that a client receives every incremental update, only that the client eventually receives the latest state, that the state clients receive is real-time (within the latency of the network), and that updates are desired as often as possible.
+
+### Declaration
+
+All lanes are declared inside Web Agents as fields annotated with `@SwimLane`. The parameter inside this annotation is the lane's **laneUri**. Recall that every Web Agent has a universal, logical address known as its **nodeUri**; `laneUri`s are simply the equivalent counterpart for lanes.
+
+The following declaration is sufficient to make the `data` lane of every `UnitAgent` addressable by the laneUri `"data"`:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.DemandMapLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("data")
+  DemandMapLane<String, String> data;
+}
+```
+
+Internally, lanes are always backed by `swim.structure.Value`s, regardless of their parametrized types. Under the hood, lanes use **forms** to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types provided that a form for that data type exists. Even custom Java classes can be lane types, provided that forms for those classes exist. We will further discuss this topic in a more advanced cookbook.
+
+### Instantiation and `onCue()`
+
+The `AbstractAgent` class comes with utility methods to construct runnable lanes. Recall, however, that developers rarely instantiate Web Agents by explicitly invoking their constructors. The recommended pattern for adding a demand map lane to an Agent is instead to:
+
+- Exclude constructors entirely from Web Agents
+- Use the `demandMapLane()` method to instantiate the lane; note that this is a parametrized method
+- Through a builder pattern, override the lane's `onCue()` and `onSync()` methods
+- Make the underlying map lane, cue the demand map lane in it's `didUpdate()` method (see next section for more)
+
+This **onCue(K key)** lifecycle callback is executed every time **cue(K key)** is called against the lane.
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.DemandMapLane;
+
+public class UnitAgent extends AbstractAgent {
+
+  @SwimLane("data")
+  protected DemandMapLane<String, String> data = this.<String, String>demandMapLane()
+      .onCue((key, uplink) -> {
+        return "Number:" + Math.random();
+      })
+      .onSync(uplink -> {
+        return Collections.emptyIterator();
+      });
+}
+```
+
+{% include alert.html title='Caution' text='If you have multiple lanes within an Agent type, ensure that their laneUris are not identical. Suppose we declare two different value lanes within our <strong>UnitAgent</strong> with laneUri <strong>"info"</strong>; how does the Swim runtime know which one to set? That said, reusing laneUris <strong>across</strong> Agent types is perfectly acceptable, as requests corresponding to these are guaranteed to have different nodeUris.' %}
+
+### Linking to Map Lane and `cue(K key)`
+
+Demand map lanes are backed by a **map lane** so that when a key value pair is updated, the demand map lane will process or decode the data, only if an uplink is subscribed. We can implement this by making the map lane's `didUpdate()` callback `cue()` the demand map lane. In the following example, the demand map lane `data` is backed by the the map lane `raw`, and will fetch from it on demand:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.DemandMapLane;
+import swim.api.lane.MapLane;
+
+import java.util.Base64;
+
+public class UnitAgent extends AbstractAgent {
+
+  @SwimLane("raw")
+  protected MapLane<String, String> raw = this.<String, String>mapLane()
+    .didUpdate((key, newValue, oldValue) -> this.data.cue(key));
+
+  @SwimLane("data")
+  protected DemandMapLane<String, String> data = this.<String, String>demandMapLane()
+    .onCue((key, uplink) -> decodeRaw(key))
+    .onSync(uplink -> this.raw.keyIterator());
+
+  private String decodeRaw(String key) {
+    final String encoded = this.raw.get(key);
+    if (encoded == null) return "";
+    final String decoded = new String(Base64.getDecoder().decode(encoded.getBytes()));
+    System.out.println(nodeUri() + ": Decoded raw data to: "+ decoded);
+    return decoded;
+  }
+}
+```
+
+As shown in the example, the demand map lane allows us to only decode data when it is needed, reducing the memory footprint of agents.
+
+### Reading from Demand Map Lanes
+
+There are two ways to read data from demand map lanes, both of which require opening a downlink.
+
+The simpler approach is to simply call `get(K key)` on the downlink to read its value at `key` at the time of the invocation.
+
+The far more powerful approach uses the fact that map downlinks **also** have access to `didUpdate()`. This enables an event-driven style of programming where client programs are treated as completely in sync with the server. And, excluding network latency and backpressure regulation of network packets, they basically are.
+
+The following is an example of how the Swim client would create a downlink to the `data` demand map lane we created in the previous code snippet:
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.api.downlink.MapDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Form;
+
+public class CustomClient {
+
+  public static void main(String[] args) {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+
+    final String hostUri = "warp://localhost:9001";
+
+    final MapDownlink<String, String> dataDownlink =
+        swimClient.downlinkMap()
+          .keyForm(Form.forString()).valueForm(Form.forString())
+          .hostUri(hostUri)
+          .nodeUri("/unit").laneUri("data?name=bar")
+          .didUpdate((key, newValue, oldValue) -> {
+            System.out.println("data updated entry " + key + " : '" + newValue + "'");
+          }).open();
+    }
+}
+```
+
+### Filtering Events by Key
+
+We can also restrict the keys for which an uplink will receive events for by changing the subscription request to use query strings.
+
+Modifying the previous example, adding a query string `name` in the `laneUri` of the client's downlink request will allow the server to filter events:
+
+```java
+// swim/basic/CustomClient.java
+final MapDownlink<String, String> dataDownlink =
+    swimClient.downlinkMap()
+        .keyForm(Form.forString()).valueForm(Form.forString())
+        .hostUri(hostUri)
+        .nodeUri("/unit").laneUri("data?**name=bar**")
+        .didUpdate((key, newValue, oldValue) -> {
+            System.out.println("data updated entry " + key + " : '" + newValue + "'");
+        }).open();
+```
+
+Server side, we can now query the `laneUri` of the uplink passed to `onCue` and `onSync` and only return events where the key matches:
+
+```java
+// swim/basic/UnitAgent.java
+@SwimLane("data")
+protected DemandMapLane<String, String> data = this.<String, String>demandMapLane()
+    .onCue((key, uplink) -> {
+        final String name = uplink.laneUri().query().get("name");
+        return (key.equals(name)) ? decodeRaw(key) : null;
+    })
+    .onSync(uplink -> {
+        final String name = uplink.laneUri().query().get("name");
+        return (this.raw.containsKey(name)) ?
+            Collections.singletonList(name).iterator() : Collections.emptyIterator();
+    });
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/demand_map_lanes).
diff --git a/src/_rust_backend/demand-value-lanes.md b/src/_rust_backend/demand-value-lanes.md
new file mode 100644
index 0000000..2d28d9c
--- /dev/null
+++ b/src/_rust_backend/demand-value-lanes.md
@@ -0,0 +1,159 @@
+---
+title: Demand Value Lanes
+short-title: Demand Value Lanes
+description: "Define persistent properties of Web Agents, and lazily generate events on state changes."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/demand_value_lanes
+redirect_from:
+  - /rust/tutorials/demand-value-lanes/
+  - /rust/reference/demand-value-lanes.html
+---
+
+In the [Web Agents guide]({% link _rust_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+
+Lanes come in many flavors, but every lane type exposes:
+
+- A **means to act** on this lane
+- Customizable **lifecycle callbacks** that execute during the runtime of this action
+- Various means to **strongly type** (i.e. _parametrize_) the lane
+- Universal WARP **subscriptions** to this lane
+
+A **demand lane** does not store any value, instead they are backed by a [value lane]({% link _rust_backend/value-lanes.md %}) and retrieve values purely on demand. Demand lanes **lazily** generate events for the value lane, only when there is an uplink ready to receive the event. The lane meets these requirements:
+
+- Every demand lane can be **cue**-ed, signalling there is an event to be sent to the uplinks, if ready. This is done in the value lane's `didSet()` method
+- Doing so will trigger its **onCue()** callback
+- The parameter on a demand lane indicates the type of value that it fetches
+- Demand lane state and lifecycle can be subscribed to via both **value downlinks** and general-purpose **event downlinks**
+
+Demand lanes can be cue()-ed at extremely high rates, and only as many events will be generated as each uplink can handle; the rate of event generation is tailored per uplink.
+
+Demand lanes are ideal for publishing statistical events, where it isn't important that a client receives every incremental update, only that the client eventually receives the latest state, that the state clients receive is real-time (within the latency of the network), and that updates are desired as often as possible.
+
+### Declaration
+
+All lanes are declared inside Web Agents as fields annotated with `@SwimLane`. The parameter inside this annotation is the lane's **laneUri**. Recall that every Web Agent has a universal, logical address known as its **nodeUri**; `laneUri`s are simply the equivalent counterpart for lanes.
+
+The following declaration is sufficient to make the `data` lane of every `UnitAgent` addressable by the laneUri `"data"`:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.DemandLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("data")
+  DemandLane<String> data;
+}
+```
+
+Internally, lanes are always backed by `swim.structure.Value`s, regardless of their parametrized types. Under the hood, lanes use **forms** to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types provided that a form for that data type exists. Even custom Java classes can be lane types, provided that forms for those classes exist. We will further discuss this topic in a more advanced cookbook.
+
+### Instantiation and `onCue()`
+
+The `AbstractAgent` class comes with utility methods to construct runnable lanes. Recall, however, that developers rarely instantiate Web Agents by explicitly invoking their constructors. The recommended pattern for adding a demand lane to an Agent is instead to:
+
+- Exclude constructors entirely from Web Agents
+- Use the `demandLane()` method to instantiate the lane; note that this is a parametrized method
+- Through a builder pattern, override the lane's `onCue()` method
+- Make the underlying value lane cue the demand lane in it's `didSet()` method (see next section for more)
+
+This **onCue()** lifecycle callback is executed every time **cue()** is called against the lane.
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.DemandLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("data")
+  DemandLane<String> data = this.<String>demandLane().onCue(uplink -> {
+    return "Number:" + Math.random();
+  });
+}
+```
+
+{% include alert.html title='Caution' text='If you have multiple lanes within an Agent type, ensure that their laneUris are not identical. Suppose we declare two different value lanes within our <strong>UnitAgent</strong> with laneUri <strong>"info"</strong>; how does the Swim runtime know which one to set? That said, reusing laneUris <strong>across</strong> Agent types is perfectly acceptable, as requests corresponding to these are guaranteed to have different nodeUris.' %}
+
+### Linking to Value Lane and `cue()`
+
+Demand lanes are backed by a **value lane** so that when a value is set, the demand lane will process or decode the data, only if an uplink is subscribed. We can implement this by making the value lane's `didSet()` callback `cue()` the demand lane. In the following example, the demand lane `data` is backed by the value lane `raw`, and will fetch from it on demand:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.DemandLane;
+import swim.api.lane.ValueLane;
+
+import java.util.Base64;
+
+public class UnitAgent extends AbstractAgent {
+
+  @SwimLane("raw")
+  ValueLane<String> raw = this.<String>valueLane().didSet((n, o) -> this.data.cue());
+
+  @SwimLane("data")
+  DemandLane<String> data = this.<String>demandLane().onCue(uplink -> decodeRaw());
+
+  // Transform raw data to the desired format
+  private String decodeRaw() {
+    final String encoded = this.raw.get();
+    if (encoded == null) return "";
+    final String decoded = new String(Base64.getDecoder().decode(encoded.getBytes()));
+    System.out.println(nodeUri() + ": Decoded raw data to: "+ decoded);
+    return decoded;
+  }
+}
+```
+
+As shown in the example, the demand lane allows us to only decode data when it is needed, reducing the memory footprint of agents.
+
+### Reading from Demand Lanes
+
+There are two ways to read data from demand lanes, both of which require opening a downlink.
+
+The simpler approach is to simply call `get()` on the downlink to read its value at the time of the invocation.
+
+The far more powerful approach uses the fact that value downlinks _also_ have access to `didSet()`. This enables an event-driven style of programming where client programs are treated as completely in sync with the server. And, excluding network latency and backpressure regulation of network packets, they basically are.
+
+The following is an example of how the Swim client would create a downlink to the `data` demand lane we created in the previous code snippet:
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.api.downlink.ValueDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Form;
+
+public class CustomClient {
+
+  public static void main(String[] args) {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+
+    final String hostUri = "warp://localhost:9001";
+
+    final ValueDownlink<String> dataDownlink =
+      swimClient.downlinkValue()
+        .valueForm(Form.forString())
+        .hostUri(hostUri)
+        .nodeUri("/unit").laneUri("data")
+        .didSet((n, o) -> System.out.println("data updated from '" + o + "' to '" + n + "'"))
+        .open();
+  }
+}
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/demand_value_lanes).
diff --git a/src/_rust_backend/downlinks.md b/src/_rust_backend/downlinks.md
new file mode 100644
index 0000000..49c5e12
--- /dev/null
+++ b/src/_rust_backend/downlinks.md
@@ -0,0 +1,102 @@
+---
+title: Downlinks
+short-title: Downlinks
+description: "Share data across Web Agents and clients through persistent, bidirectionally-streaming lane references."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/downlinks
+redirect_from:
+  - /rust/tutorials/downlinks/
+  - /rust/reference/downlinks.html
+---
+
+In the [Web Agents guide]({% link _rust_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects** and **lanes** are **fields**. **Downlinks** are bidirectionally-streaming, persistent **subscriptions** to lanes.
+
+Downlinks come in many flavors, but there are only two broad downlink categories. An **event downlink** can subscribe to any lane and provides:
+
+- A single customizable **onEvent(V event)** callback function that executes upon every update to the lane
+- A means to **strongly type** (i.e. **parametrize**) the downlink
+- Transparent, eventually-consistent streaming of reads
+
+The other category of downlinks is **storage-lane** specific, i.e there is a one-to-one correspondence between each downlink type and a **non-command** lane type. **Value downlinks** work with value lanes, **map downlinks** work with map lanes, **list downlinks** work with list lanes, and so on. Despite the one-to-one restriction with lane types, these are the downlinks that you'll mostly be using, as each offers:
+
+- Various customizable **callback functions**, disambiguated by event type and containing properly-structured parameters; such callbacks can, for example, perform analytics or update UI widgets
+- A means to **act** on its target lane
+- A means to **strongly type** (i.e. **parametrize**) the downlink
+- Transparent, eventually-consistent streaming of both reads and writes
+
+Use event downlinks only if you wish to reuse the same reference among multiple target lane types, prevent writes from your downlink, or listen to a command lane.
+
+There are two big things to manage when dealing with downlinks: **data** and **connections**. This guide will focus heavily on the former; we will expand on connection management in a future, more advanced article.
+
+### Declaration
+
+All downlink classes can be imported from package `swim.api.downlink`.
+
+### Usage
+
+Downlinks must be instantiated against Swim refs, i.e. specific server-side or client-side objects. Although several permutations exist, the builder pattern is the same each time:
+
+1. Invoke `downlink()` against your ref for an event downlink, or `downlinkFoo()` for a foo downlink (e.g. `downlinkMap()` for a map downlink)
+1. Build the downlink's `hostUri` using `hostUri()` (this step can only be omitted if your Swim ref is server-side, and you are targeting a lane within the same server), the downlink's `nodeUri` using `nodeUri()`, and the downlink's `laneUri` using `laneUri()`
+1. Override any lifecycle callback functions, which default to no-ops
+1. Optionally parametrize the downlink
+1. Optionally set the **keepSynced** (pull all existing data from a lane before processing new updates; defaults to `false`) and **keepLinked** (enable consistent **reads** from the downlink (unnecessary for write-only downlinks); defaults to `true`) flags
+1. Invoke `open()` on the downlink to initiate data flow
+1. When finished, invoke `close()` on the downlink to stop data flow
+
+#### Lifecycle callbacks and updating lanes
+
+Every event downlink has a customizable `onEvent(V event)` callback function that specifies the action to take upon every event received by the target lane.
+
+For all other (i.e. lane-specific) downlinks, recall that every data-storing lane can be acted upon by methods specific to that lane type (e.g. `set` for value lanes; `put`, `remove`, `drop`, `take`, and `clear` for map lanes). These options also exist on correctly-configured lane-specific downlinks. Furthermore, for every such method `foo`, each downlink has a `didFoo(Object... args)` method that follows similar lifecycle semantics to `onEvent()`, but with more useful callback parameters. For example, every `MapDownlink<K, V>` has access to `didUpdate(K key, V newValue, V oldValue)`, `didRemove(K key, V oldValue)`, `didDrop(int dropCount)`, `didTake(int keepCount)`, and `didClear()` methods.
+
+#### Parametrization
+
+Unlike with lanes, which additionally offer parametrized methods, downlink parametrization **requires** providing ``swim.structure.Forms` through a builder pattern.
+
+#### Java
+
+Client-side, downlinks must be issued from a `ClientRuntime`, but the builder syntax is otherwise identical:
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.api.downlink.MapDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Form;
+
+class CustomClient {
+
+  public static void main(String[] args) throws InterruptedException {
+
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+
+    final String hostUri = "warp://localhost:9001";
+    final String nodeUriPrefix = "/unit/";
+
+    // map downlink example
+    final MapDownlink<String, Integer> link = swimClient.downlinkMap()
+        .keyForm(Form.forString()).valueForm(Form.forInteger())
+        .hostUri(hostUri).nodeUri(nodeUriPrefix+"0").laneUri("shoppingCart")
+        .keepLinked(false)
+        .open();
+    // Remember that downlinks can write, too!
+    link.put("FromClientLink", 25);
+  }
+}
+```
+
+Server-side, downlinks are explained in the [Server Downlinks guide]({% link _rust_backend/server-downlinks.md %}).
+
+### JavaScript
+
+For details on using downlinks with JavaScript, visit the [**downlinks**]({% link _frontend/downlinks.md %}) article in our [**frontend documentation**](/frontend)
+
+Furthermore, the tutorial application demonstrates [using value downlinks](https://github.com/swimos/tutorial/blob/master/ui/pie.html#L58-L67){:data-proofer-ignore=''} and [map downlinks](https://github.com/swimos/tutorial/blob/master/ui/chart.html#L69-L79){:data-proofer-ignore=''} issued against a Swim client instance. Note the language-level loss of parametrization, but the otherwise-identical syntax to Java.
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/downlinks).
diff --git a/src/_rust_backend/forms.md b/src/_rust_backend/forms.md
new file mode 100644
index 0000000..f4bff3d
--- /dev/null
+++ b/src/_rust_backend/forms.md
@@ -0,0 +1,187 @@
+---
+title: Forms
+short-title: Forms
+description: "Parametrize your lanes with and links with custom types."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/forms
+redirect_from:
+  - /rust/tutorials/forms/
+  - /rust/reference/forms.html
+---
+
+Recall that internally, as in all previous "... Lanes" cookbooks to date, `swim.structure.Value` is the type of every lane, regardless of its parametrized type.
+
+More formally, any type -- even a custom type -- can serve as a type within a lane. The only requirement is to define a transformation for that type from Java's built-in [nominal type system](https://en.wikipedia.org/wiki/Nominal_type_system) to Swim's `swim.structure.Value`-defined [structural type system](https://en.wikipedia.org/wiki/Structural_type_system).
+
+This offers a handful of advantages, primarily that `swim.structure.Value` types have general, well-defined serializations to Recon (this also applies to JSON, XML, and more, though that is less pertinent to this guide).
+
+In essence, this means that clients can connect to Lanes directly, and authors of Web Agents don't have to worry about explicit (de)serializations in the server-side code.
+
+### Transforming Values
+
+An instance of `swim.structure.Form<T>` handles transformations between `Value` and `T`.
+
+When declaring a lane parametrized with a type `T`, the Swim core **always** uses some `Form<T>` to manage conversions under the hood.
+
+Several methods implemented in the `BarType` class handle these transformations manually.
+
+#### Types of Forms
+
+The `swim.structure.form` package contains many out-of-the-box Forms already for a variety of common [types](https://github.com/swimos/swim/tree/main/swim-java/swim-runtime/swim-core/swim.structure/src/main/java/swim/structure/form), such as LongForm, CharacterForm, and StringForm. This is why one can declare, for example, a `MapLane<String, Long>` that works without any additional effort.
+
+For other types (e.g. custom pojos), you need to implement your own Form for that type, and tag the static accessor with @Kind.
+
+There are two methods to achieve this: the "no-magic" (explicit) way exercised in `Bartype` and through annotations as exercised in `FooType`.
+
+#### The BarType Class
+
+There are several methods responsible for handling transformations between `Value` types and a custom Java object such as `BarType`:
+
+##### **- mold()**
+
+The `mold()` method is used to convert the fields of some custom object into a Swim structure of type `Value`.
+
+```java
+// swim/basic/BarType.java
+@Override
+public Value mold(BarType barType) {
+  return Record.create(3)
+    .attr(tag())
+    .slot("i", barType.getNumber1())
+    .slot("s", barType.getString())
+    .slot("j", barType.getNumber2());
+}
+```
+
+##### **- cast()**
+
+The `cast()` method is responsible for the inverse operation, parsing a `Value` into a Java object of the class type, e.g. `BarType`
+
+```java
+// swim/basic/BarType.java
+@Override
+public BarType cast(Item value) {
+  try {
+    final Attr attr = (Attr) value.head();
+    final String barType = attr.getKey().stringValue("");
+    if (!tag().equals(barType)) {
+      return null;
+    }
+    BarType b = new BarType(value.get("i").intValue(0),
+      value.get("s").stringValue(""),
+      value.get("j").intValue(0));
+    return b;
+  } catch (Exception e) {
+    return null;
+  }
+}
+```
+
+##### **- tag()**
+
+By default, the `Attr` associated with a Form, such as that in `Record.create(3).attr("fooType").slot("i", 5).slot("s", "potato");`, defaults to a camelCase string of the class name. The `tag()` method can be used to explicitly set a unique id for objects of a pojo.
+
+```java
+// swim/basic/BarType.java
+class BarTypeForm extends Form<BarType> {
+  @Override
+  public String tag() {
+      return "barType";
+  }
+}
+```
+
+##### **- type()**
+
+The `type()` method is used to return the type of an object in the form of its defined class.
+
+```java
+@Override
+public Class<?> type() {
+    return BarType.class;
+}
+```
+
+#### The FooType Class
+
+The FooType class in this project sets out a method of streamlining the process of defining a custom Form through more succinct annotations.
+
+##### **- @Kind**
+
+The `@Kind` annotation is used to tag a static accessor method for a custom Form.
+
+```java
+// swim/basic/FooType.java
+@Kind
+private static Form<FooType> form;
+```
+
+##### **- @Tag**
+
+A shorthand way of overriding the default classname `Attr` picked up by the reflection api.
+
+```java
+// swim/basic/FooType.java
+@Tag("fooType")
+```
+
+##### **- @Member**
+
+By default, the variable name of a class member will get picked up as the default attribute. However, as in `@Tag`, this string can be overriden using the `@Member` annotation.
+
+This is by no means required, though when used `@Member` will change the attribute used in Recon serialization. This can prove helpful in Forms when one wishes to use shorthand value names internally but more explicit names in serialization (or vise versa).
+
+```java
+// swim/basic/FooType.java
+public class FooType {
+  @Member("i")
+  private int i = 0;
+  @Member("s")
+  private String s = "";
+  ...
+```
+
+**As an exercise, imagine what would need to happen to achieve the same thing in BarType.java**
+
+##### **- form()**
+
+The `form()` method is used to simply return the form. In this example, it is best practice to check whether the form does not exist before returning, due to potentially JVM-dependent class-loading behavior.
+
+```java
+// swim/basic/FooType.java
+public static Form<FooType> form() {
+    if(form == null) {
+      form = Form.forClass(FooType.class);
+    }
+    return form;
+}
+```
+
+### Advanced Topic: Composability
+
+Consider the problem of creating Forms for some type `TrickyType`, whose fields are other pojos that each have their own Forms.
+
+To manually build a Form for this type by explictly implementing some `Form<TrickyType>` (e.g. like what was done with `BarType`), we can expect a clean implementation to call the other Forms' `mold()` and `cast()` methods, following a fairly predictable pattern.
+
+Because it's so predictable, the annotation style Form generation can still be used, provided that these field pojos themselves have properly staged `Forms`. This is exercised via `BazType` in the companion app.
+
+```java
+// swim/basic/BazType.java
+@Tag("bazType")
+public class BazType {
+  private FooType f = new FooType();
+  private BarType b = new BarType();
+  public BazType(FooType f, BarType b) {
+    this.f = f;
+    this.b = b;
+  }
+  ...
+}
+```
+
+This clean composability also enables some of the more complicated forms that were [linked](https://github.com/swimos/swim/tree/main/swim-java/swim-runtime/swim-core/swim.structure/src/main/java/swim/structure/form) earlier. For example, one can get a working `Form<List<FooType>` handle by simply doing `Form<List<FooType> = Form.forList(FooType.form())` (see [here](https://github.com/swimos/swim/blob/main/swim-java/swim-runtime/swim-core/swim.structure/src/main/java/swim/structure/Form.java#L221-L246){:data-proofer-ignore=''}). Even something like a `Form<List<List<BazType>` could be created similarly!
+
+### Try It Yourself
+
+A standalone project that demonstrates each method of defining a Form for a custom Java class can be found [here](https://github.com/swimos/cookbook/tree/master/forms).
diff --git a/src/_backend/fundamentals.md b/src/_rust_backend/fundamentals.md
similarity index 77%
rename from src/_backend/fundamentals.md
rename to src/_rust_backend/fundamentals.md
index f24daed..b9dc894 100644
--- a/src/_backend/fundamentals.md
+++ b/src/_rust_backend/fundamentals.md
@@ -5,8 +5,8 @@ description: "Learn about SwimOS fundamentals and concepts."
 group: Getting Started
 layout: documentation
 redirect_from:
-  - /fundamentals/
-  - /concepts/fundamentals.html
+  - /rust/fundamentals/
+  - /rust/concepts/fundamentals.html
 ---
 
 Streaming Data Applications are an emerging architectural approach that affords application functionality to streaming data. The three foundational components of Streaming Data Applications are:
@@ -18,7 +18,7 @@ Streaming Data Applications are an emerging architectural approach that affords
 ## Stateful Objects
 
 A Stateful Object is a simple object representation of a business entity that lives amongst your streaming data. It is very much like a Plain Old Java Object (POJO) equipped with some additional superpowers. A Stateful Object continuously consumes updates of synced state. For each update, it computes new state that automatically gets synced to listeners without explicit action or coordination.
- 
+
 SwimOS’s implementation of Stateful Objects are called Web Agents. They are web-addressable, distributed objects for business entities. Like a traditional object, they marry state with behavior. Instead of requests and queries, Web Agents subscribe to updates or have them pushed directly during ingestion whenever information for the underlying entity comes in. Web Agents subscribe to all the state needed to take action for its corresponding entity. We call this full-context business logic because it takes in first-order entity state, as well as the first-order states of requisite entities, and then the second-order state generated by stream processing, and finally, all applicable derived state from other Web Agents.
 
 ## Streaming APIs
@@ -26,7 +26,7 @@ SwimOS’s implementation of Stateful Objects are called Web Agents. They are we
 With polling, load scales with how often you ask. With streaming, load scales with how often data changes. True real-time is impossible with polling because you would have to poll infinitely fast. E-Tag caching has provide a big improvement, but cannot achieve the degree of low-latency compared to streaming.
 
 Streaming APIs move data the moment it is available and keep it moving until the data has been sent to all subscribers. Producers are decoupled from consumers because the Streaming API implementation handles the routing and hopefully enforcing access controls. Using efficient routing, a stream’s journey can satisfy multiple subscribers along the way achieving efficiency gains. Rigid point-to-point methods preclude such gains.
- 
+
 With an optimal, massively scalable Streaming API implementation like that of SwimOS, the Streaming API will use multiplexing to batch potentially massive concurrent updates into a single stream.
 
 Additionally, while events are compact, they are verbose compared to differential state sync methods. A recurring event may require zero update to an entity's state based on business logic, or it might require advancing or flipping a bit or two, or anywhere less than the event’s payload. This is because business logic can determine the impact on state by executing its own very specific business logic. Furthermore, this underscores a point that can be easy to miss, when a system syndicates events, every recipient has upon itself the requirement to process that event. An event routinely reaching 100s or 1000s or more recipients within the network will dramatically compound the toll of event processing in the system. On the other hand, if the system impels execution of business logic and only transmits the resulting state change deltas, rather than compounding the toll of event processing, the beneficial derived state that results from event processing is advantageously compounded instead. For this reason, SwimOS uses differential state sync as opposed to simple event propagation for its Streaming API implementation.
@@ -49,22 +49,22 @@ Swim unifies the traditionally disparate roles of database, message broker, job
 
 ### Web Agents
 
-Swim applications consist of interconnected, distributed objects, called [Web Agents]({% link _backend/web-agents.md %}). Each Web Agent has URI address, like a REST endpoint. But unlike RESTful Web Services, Web Agents are stateful, and accessed via streaming APIs.
+Swim applications consist of interconnected, distributed objects, called [Web Agents]({% link _rust_backend/web-agents.md %}). Each Web Agent has URI address, like a REST endpoint. But unlike RESTful Web Services, Web Agents are stateful, and accessed via streaming APIs.
 
 ### Lanes
 
-If Web Agents are distributed objects, then [lanes]({% link _backend/lanes.md %}) serve as the properties and methods of those objects. Lanes come in many flavors: **value lanes**, **map lanes**, **command lanes**, and **join lanes**, to name a few. Many lanes are internally persistent, acting like encapsulated database tables.
+If Web Agents are distributed objects, then [lanes]({% link _rust_backend/lanes.md %}) serve as the properties and methods of those objects. Lanes come in many flavors: **value lanes**, **map lanes**, **command lanes**, and **join lanes**, to name a few. Many lanes are internally persistent, acting like encapsulated database tables.
 
 ### Links
 
-Distributed objects need a way to communicate. [Links]({% link _backend/links.md %}) establishes active references to lanes of Web Agents, transparently streaming bidirectional state changes to keep all parts of an application in sync, without the overhead of queries or remote procedure calls.
+Distributed objects need a way to communicate. [Links]({% link _rust_backend/links.md %}) establishes active references to lanes of Web Agents, transparently streaming bidirectional state changes to keep all parts of an application in sync, without the overhead of queries or remote procedure calls.
 
 ### Recon
 
-Communication only works if all parties understand each other. Swim natively speaks a universal, structured data language, called [Recon]({% link _backend/recon.md %}). A superset of JSON, XML, Protocol Buffers, and more, Recon naturally translates into many languages. Declare, definine, and utilize Web Agents and their properties using these configuration files.
+Communication only works if all parties understand each other. Swim natively speaks a universal, structured data language, called Recon. A superset of JSON, XML, Protocol Buffers, and more, Recon naturally translates into many languages. Declare, definine, and utilize Web Agents and their properties using these configuration files.
 
 ### WARP
 
-The [Web Agent Remote Protocol (WARP)]({% link _backend/warp.md %}) enables bidirectional links to streaming API endpoints, called lanes, of URI-addressed distributed objects, called nodes, that run Web Agents.
+The Web Agent Remote Protocol (WARP) enables bidirectional links to streaming API endpoints, called lanes, of URI-addressed distributed objects, called nodes, that run Web Agents.
 
-Continue reading to learn more about [Web Agents]({% link _backend/web-agents.md %}), [Lanes]({% link _backend/lanes.md %}), [Links]({% link _backend/links.md %}), and [Recon]({% link _backend/recon.md %}). Or dive into the [tutorials]({% link _tutorials/index.md %}) to learn by doing.
+Continue reading to learn more about [Web Agents]({% link _rust_backend/web-agents.md %}), [Lanes]({% link _rust_backend/lanes.md %}), [Links]({% link _rust_backend/links.md %}), and Recon. Or dive into the [tutorials]({% link _rust_tutorials/index.md %}) to learn by doing.
diff --git a/src/_rust_backend/http-lanes.md b/src/_rust_backend/http-lanes.md
new file mode 100644
index 0000000..7d9e482
--- /dev/null
+++ b/src/_rust_backend/http-lanes.md
@@ -0,0 +1,121 @@
+---
+title: HTTP Lanes
+short-title: HTTP Lanes
+description: "Expose a HTTP endpoint for Web Agents."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/http_lanes
+redirect_from:
+  - /rust/tutorials/http-lanes/
+  - /rust/reference/http-lanes.html
+---
+
+In previous guides, we have seen how Swim applications consist of interconnected [Web Agents]({% link _rust_backend/web-agents.md %}) with properties and methods in the form of [Lanes]({% link _rust_backend/command-lanes.md %}).
+
+**HTTP Lanes** accept HTTP requests and respond enabling Web Agents to expose **endpoints**. This allows Web Agent's state to be viewed or modified from outside of Swim applications through the use of **REST APIs**.
+
+### Declaration
+
+All lanes are declared inside Web Agents as fields annotated with `@SwimLane`. The parameter inside this annotation is the lane's **laneUri**. Recall that every Web Agent has a universal, logical address known as its **nodeUri**; `laneUri`s are simply the equivalent counterpart for lanes.
+
+The following declaration is sufficient to make the `http` lane of every `UnitAgent` addressable by the laneUri `"http"`:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.http.HttpLane;
+import swim.structure.Value;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("http")
+  HttpLane<Value> http;
+}
+```
+
+### Instantiation
+
+The `AbstractAgent` class comes with utility methods to construct runnable lanes. Recall, however, that developers rarely instantiate Web Agents by explicitly invoking their constructors. The recommended pattern for adding a HTTP lane to an Agent is instead to:
+
+- Exclude constructors entirely from Web Agents
+- Use the `httpLane()` method to instantiate the lane; note that this is a parametrized method
+- Through a builder pattern, override the lane's `doRespond()` method, returning a HTTP response
+- The lane is addressable by combining `hostUri`, `nodeUri` and a query parameter of the lane name (example below).
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.http.HttpLane;
+import swim.http.HttpResponse;
+import swim.http.HttpStatus;
+import swim.structure.Value;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("http")
+  HttpLane<Value> http = this.<Value>httpLane()
+      .doRespond(request -> {
+        return HttpResponse.from(HttpStatus.OK).body("Hello World");
+      });
+}
+```
+
+The `http` lane in the example above, when running on `localhost:9001` and agent has nodeUri `/unit`, can be addressed with: `localhost:9001/unit?lane=http`. A HTTP response with body of `Hello World` will be returned to every request.
+
+### HTTP Methods
+
+The `HttpRequest` object, passed to the callback method of the lane, has access to the HTTP method of the request with `method()`, we can use this to determine the operation required. Here we add the ability to alter the state of an agent by using a `POST` request:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.http.HttpLane;
+import swim.api.lane.ValueLane;
+import swim.http.HttpMethod;
+import swim.http.HttpResponse;
+import swim.http.HttpStatus;
+import swim.http.MediaType;
+import swim.recon.Recon;
+import swim.structure.Value;
+
+public class UnitAgent extends AbstractAgent {
+
+  @SwimLane("state")
+  ValueLane<Value> state = this.<Value>valueLane()
+      .didSet((newValue, oldValue) -> {
+        System.out.println("State changed from " + Recon.toString(oldValue) + " to " + Recon.toString(newValue));
+      });
+
+  @SwimLane("http")
+  HttpLane<Value> http = this.<Value>httpLane()
+      .doRespond(request -> {
+         **if (HttpMethod.POST.equals(request.method())) state.set(request.entity().get());**
+          return HttpResponse.from(HttpStatus.OK).body(Recon.toString(state.get()), MediaType.applicationXRecon());
+        });
+}
+```
+
+### Content Type
+
+As well as **Recon**, HTTP Lanes also allow for different content types to be returned in the response body such as **Json**. Simply add the media type when setting the body of the HTTP response.
+
+Here we create a new lane in our previous example to return a Json response:
+
+```java
+// swim/basic/UnitAgent.java
+  @SwimLane("httpJson")
+  HttpLane<Value> httpJson = this.<Value>httpLane()
+      .doRespond(request ->
+        HttpResponse.from(HttpStatus.OK).body(Json.toString(state.get()), MediaType.applicationJson()));
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/http_lanes).
diff --git a/src/_rust_backend/index.md b/src/_rust_backend/index.md
new file mode 100644
index 0000000..b4f62db
--- /dev/null
+++ b/src/_rust_backend/index.md
@@ -0,0 +1,9 @@
+---
+title: Backend
+permalink: /rust/backend/
+layout: documentation
+description: "Backend SwimOS"
+toc: false
+---
+
+{% include docs-listing.html %}
diff --git a/src/_rust_backend/introspection.md b/src/_rust_backend/introspection.md
new file mode 100644
index 0000000..dcb0d04
--- /dev/null
+++ b/src/_rust_backend/introspection.md
@@ -0,0 +1,152 @@
+---
+title: Introspect a Swim server
+short-title: Swim Meta APIs
+description: "How to introspect a Swim server and obtain runtime stats"
+group: Utilities
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/introspection
+redirect_from:
+  - /rust/guides/introspection.html
+---
+
+Introspection allows you to obtain runtime information about a Swim server, including:
+
+- Compute and memory metrics
+- List running nodes
+- List lanes of a node
+- Logs
+
+_We will be demonstrating introspection on the corresponding cookbook server and so use host `warp://localhost:9001`.
+Feel free to follow along or change commands to match your server.
+This guide uses the [`swim-cli`]({% link _rust_backend/cli.md %}) extensively._
+
+## Enabling Introspection
+
+Include the following line in a Swim application's `server.recon` config file to specify that introspection should be enabled.
+
+```
+@kernel(class: "swim.meta.MetaKernel")
+```
+
+This will start a `MetaKernel` responsible for opening additional nodes and endpoints providing meta information.
+
+## Meta Nodes
+
+Two types of meta node are now available for downlinking:
+
+- The `swim:meta:mesh` node, which provides server wide meta details.
+- The `swim:meta:node/{node_uri}` nodes, which provide node specific meta details.
+
+These meta nodes behave similarly to normal nodes and so can be downlinked from within a swim application or using the `swim-cli`.
+Various lanes are opened within these nodes which provide access to different data, these lanes will be detailed in the following sections.
+
+The `{node_uri}` in `swim:meta:node/{node_uri}` must be substituted with the node URI of the node to be introspected.
+For example, the node `/building/1` (in the cookbook) will have a meta node of `swim:meta:node//building/1`.
+When using the command line it is necessary to encode the `/` characters in the node URI to `%2f` and so with the swim-cli `swim:meta:node/%2fbuilding%2f1` is used.
+
+## Pulse
+
+Available on both `swim:meta:mesh` and `swim:meta:node/`, the simplest thing we can do is downlink the `pulse` lane.
+This will provide various metrics about the introspection target, including agent count, compute time and link counts.
+
+```
+swim-cli sync -h warp://localhost:9001 -n swim:meta:mesh -l pulse
+```
+
+Output:
+
+```
+{partCount:2,hostCount:2,nodeCount:24,agents:{agentCount:49,execRate:31929,execTime:905996100,timerEventRate:21,timerEventCount:1622},downlinks:{linkCount:20},uplinks:{linkCount:20,eventRate:20,eventCount:1642},system:{cpuTotal:1600,memUsage:11875803136,memTotal:34267426816,diskUsage:1799050371072,diskTotal:2500238229504,startTime:1693840004973}}
+```
+
+## List Nodes
+
+The `nodes` lane on `swim:meta:mesh` provides access to a list of all nodes and the agents running within them.
+
+Trying this on the introspection cookbook server:
+
+```
+swim-cli sync -h warp://localhost:9001 -n swim:meta:mesh -l nodes
+```
+
+Output:
+
+```
+...
+@update(key:"/building/1/room/4"){nodeUri:"/building/1/room/4",created:1693908245376,agents:{"swim.introspection.RoomAgent","swim.introspection.RoomSimulatorAgent"}}
+@update(key:"/building/1/room/5"){nodeUri:"/building/1/room/5",created:1693908245377,agents:{"swim.introspection.RoomAgent","swim.introspection.RoomSimulatorAgent"}}
+@update(key:"/building/1"){nodeUri:"/building/1",created:1693908245375,agents:{"swim.introspection.BuildingAgent"}}
+...
+```
+
+We see that the server has several `building` and `room` nodes, we have a URI, start time and agent list for each.
+Notice the room nodes have two agents, a `RoomAgent` and `RoomSimulatorAgent`.
+
+This lane can also list all child node URIs of a parent, giving the ability to list all nodes of a given type.
+We can do this by adding a parameter onto the `nodes` lane with `#` followed by the pattern of a node URI, ending with `/`.
+For clarity, here are some example parameters that can be used and their function:
+
+- `nodes#/`: List the first part of all node URIs (this will just be `/building` in the cookbook as all nodes are children).
+- `nodes#/building/`: List all building nodes.
+- `nodes#/building/2/room/`: List all room nodes in building 2.
+
+Using the second option as an example:
+
+```
+swim-cli sync -h warp://localhost:9001 -n swim:meta:mesh -l nodes#/building/
+```
+
+Output:
+
+```
+@update(key:"/building/1"){nodeUri:"/building/1",created:1693908245375,childCount:1,agents:{"swim.introspection.BuildingAgent"}}
+@update(key:"/building/2"){nodeUri:"/building/2",created:1693908245380,childCount:1,agents:{"swim.introspection.BuildingAgent"}}
+```
+
+We have obtained a list of all building nodes.
+Notice that both nodes have `childCount:1`, this is because there are nodes with URIs that are children of theirs (i.e. the room agents).
+
+## List Lanes
+
+The `lanes` lane on `swim:meta:node/` provides access to a list of all lanes on a node and their types.
+
+Trying this on the introspection cookbook server, on a room agent:
+
+```
+swim-cli sync -h warp://localhost:9001 -n swim:meta:node/%2fbuilding%2f1%2froom%2f1 -l lanes
+```
+
+Output:
+
+```
+@update(key:info){laneUri:info,laneType:value}
+@update(key:lights){laneUri:lights,laneType:value}
+@update(key:occupied){laneUri:occupied,laneType:value}
+@update(key:temperature){laneUri:temperature,laneType:value}
+```
+
+## Logs
+
+The Swim framework provides agents with the ability to log messages at different levels (trace, debug, info, warn, error, fail).
+These logs can be accessed on both `swim:meta:mesh`, for server wide logs, and `swim:meta:node/`, for node specific logs.
+Simply prepend the log level desired to `Log` to obtain the lane URI to be downlinked.
+
+For example, to tail all `warn` level logs on the introspection cookbook server:
+
+```
+swim-cli sync -h warp://localhost:9001 -n swim:meta:mesh -l warnLog
+```
+
+Output:
+
+```
+@warn(time:1693926115314)"/building/1/room/3 lights on but vacant"
+...
+```
+
+## UI
+
+Swim provides a general purpose Introspection GUI, this is built upon the concepts above.
+It can be used to visualise a Swim server including nodes, lanes and pulse stats.
+
+Check out [`https://introspection.nstream.io/?host=warp://localhost:9001`](https://introspection.nstream.io/?host=warp://localhost:9001) while running the introspection cookbook or change the host parameter to point at your Swim server.
diff --git a/src/_rust_backend/join-map-lanes.md b/src/_rust_backend/join-map-lanes.md
new file mode 100644
index 0000000..05d9bd4
--- /dev/null
+++ b/src/_rust_backend/join-map-lanes.md
@@ -0,0 +1,120 @@
+---
+title: Join Map Lanes
+short-title: Join Map Lanes
+description: "Define persistent collections of properties between multiple Web Agents, and consistently stream real-time updates."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/join_map_lanes
+redirect_from:
+  - /rust/tutorials/join-map-lanes/
+  - /rust/reference/join-map-lanes.html
+---
+
+The [Join Value Lanes guide]({% link _rust_backend/join-value-lanes.md %}) demonstrates Join Value Lanes which aggregate value lanes from many agents. Similar to **Join Value Lanes**, **Join Map Lanes** aggregate **Map Lanes** across multiple agents.
+
+A **Join Map Lane** uses [downlinks]({% link _rust_backend/links.md %}) to create permanent links to **Map Lanes** and exhibits the same behaviour as [Map Lanes]({% link _rust_backend/map-lanes.md %}). Some additional properties are present:
+
+- Operations performed on a **Map Lane** are propagated via downlinks to the **Join Map Lane**.
+- A **link form** must be specified.
+- Customizable **lifecycle callbacks** that execute during the runtime of this join map lane.
+- Every join map lane can be **linked** to multiple map lanes.
+- A new **DownlinkMap** instance is returned containing an entryset containing the aggregated entrysets of the downlinked map lanes.
+- The type parameters on a join map lane indicate: the link form type, key and value types.
+
+### Declaration
+
+**Join Map Lanes** are declared similarly to **Map Lanes** but require an additional type to be defined, the **link form type**. As follows:
+
+```java
+@SwimLane("join")
+JoinMapLane<FormType, KeyType, ValueType> stateJoinMap = this.joinMapLane();
+```
+
+For the purposes of this cookbook all three types will be **String**. A join map lane is a map that can aggregate entry sets of many map lanes using downlinks. If aggregating maps of different types, a sufficient type must be used - such as a String. **Join Map Lanes** can perform **put** and **remove** operations on the map instance but the operations are not propagated via the downlinks.
+
+Usage of **Join Map Lanes** mandates downlinks to be opened to the lanes that are to be aggregated and this can be performed easily through the **didStart()** method of an agent.
+
+```java
+// swim/basic/AggregatedStatisticsAgent.java
+static class AggregatedStatisticsAgent extends AbstractAgent {
+  @SwimLane("join")
+  JoinMapLane<String, String, Integer> aggregatedStatistics = this.joinMapLane();
+
+  @Override
+  public void didStart() {
+    aggregatedStatistics.downlink("california").hostUri(HOST_URI).nodeUri("/state/california").laneUri("state").open();
+    aggregatedStatistics.downlink("texas").hostUri(HOST_URI).nodeUri("/state/texas").laneUri("state").open();
+    aggregatedStatistics.downlink("florida").hostUri(HOST_URI).nodeUri("/state/florida").laneUri("state").open();
+  }
+}
+```
+
+From here, we are able to use the lifecycle events that occur on other data structures in the same fashion; such as registering a **didUpdate()** to process the data.
+
+### A worked example
+
+In this example, we will work through joining three **Map Lanes** that hold information regarding US states and aggregate the data into a **Join Map Lane**. This aggregated data will have a **didUpdate()** callback registered that checks entries that are added to see if they exceed a threshold. If it is, then the data is logged.
+
+One agent, **StreetStatisticsAgent**, will store a given state's street data. **AggregatedStatisticsAgent** will aggregate all the **StreetStatisticsAgents** and is accessible through a **MapDownlink** which is used further on.
+
+```java
+// swim/basic/StreetStatisticsAgent.java
+static class StreetStatisticsAgent extends AbstractAgent {
+  /*
+    - Key: Street name
+    - Value: Street population
+  */
+  @SwimLane("state")
+  MapLane<String, Integer> streetStatistics = this.mapLane();
+}
+
+// swim/basic/AggregatedStatisticsAgent.java
+static class AggregatedStatisticsAgent extends AbstractAgent {
+  // Aggregated statistics of US states
+  @SwimLane("join")
+  JoinMapLane<String, String, Integer> aggregatedStatistics = this.joinMapLane();
+
+  @Override
+  public void didStart() {
+    aggregatedStatistics.downlink("california").hostUri(HOST_URI).nodeUri("/state/california").laneUri("state").open();
+    aggregatedStatistics.downlink("texas").hostUri(HOST_URI).nodeUri("/state/texas").laneUri("state").open();
+    aggregatedStatistics.downlink("florida").hostUri(HOST_URI).nodeUri("/state/florida").laneUri("state").open();
+  }
+}
+```
+
+**Join Map Lanes** require downlinks to all of the **JoinMaps** that are to be aggregated and these can be opened using the agent's **didStart()** method; in this instance, the **didStart()** method is used for convenience, however, in more complex applications [command lanes]({% link _rust_backend/command-lanes.md %}) would be more suitable. Here, downlinks are opened to three states using the Swim lane **'state'**.
+
+Bringing this together, a plane is required with the two previous agents and the appropriate lane URIs.
+
+```java
+// swim/basic/BasicPlane.java
+static class BasicPlane extends AbstractPlane {
+  @SwimRoute("/state/:name")
+  AgentRoute<StreetStatisticsAgent> mapRoute;
+
+  @SwimRoute("/join/state/:name")
+  AgentRoute<AggregatedStatisticsAgent> joinMapRoute;
+}
+```
+
+By design, operations performed on a **Join Map Lane** are not propagated through the uplinks to the **Map Lanes**. Thus, the maps to be aggregated must be populated and not inversely. **Map Lanes** are opened on a plane as discussed in the [map lane]({% link _rust_backend/map-lanes.md %}) cookbook and a **Join Map Lane** is no exception. This **Join Map Lane** logs streets that contain over 1000 residents using the **didUpdate()** method:
+
+```java
+// swim/basic/CustomClient.java
+final MapDownlink<String, Integer> join = clientRuntime.downlinkMap()
+  .keyClass(String.class)
+  .valueClass(Integer.class)
+  .hostUri(HOST_URI)
+  .nodeUri("/join/state/all")
+  .laneUri("join")
+  .didUpdate((key, newValue, oldValue) -> {
+      if (newValue > THRESHOLD) {
+          logStreet(key, newValue);
+      }
+  }).open();
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/join_map_lanes).
diff --git a/src/_rust_backend/join-value-lanes.md b/src/_rust_backend/join-value-lanes.md
new file mode 100644
index 0000000..853ef7d
--- /dev/null
+++ b/src/_rust_backend/join-value-lanes.md
@@ -0,0 +1,196 @@
+---
+title: Join Value Lanes
+short-title: Join Value Lanes
+description: "Define properties for aggregating multiple value lanes and continuously stream their state changes."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/join_value_lanes
+redirect_from:
+  - /rust/tutorials/join-value-lanes/
+  - /rust/reference/join-value-lanes.html
+---
+
+In the [Value Lanes guide]({% link _rust_backend/value-lanes.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+
+Lanes come in many flavors, but every lane type exposes:
+
+- A **means to act** on this lane
+- Customizable **lifecycle callbacks** that execute during the runtime of this action
+- Various means to **strongly type** (i.e. _parametrize_) the lane
+- Universal WARP **subscriptions** to this lane
+
+A **join value lane** uses **downlinks** to create permanent links to other value lanes and meets the following requirements:
+
+- Every join value lane can be **linked** to multiple value lanes
+- The linked values are stored as a map of entries
+- Changing the value of any of the linked value lanes, will trigger **didUpdate()** on the join value lane.
+- The parameters on a join value lane indicates the type of the keys and the type of the values that it stores
+
+### Declaration
+
+A join value lane is essentially a map, that can aggregates values of multiple agents. The data type of the key can be anything, but the data type of the value must match the data type of the value lanes that will be aggregated.
+
+```java
+// swim/basic/BuildingAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.JoinValueLane;
+
+public class BuildingAgent extends AbstractAgent {
+  @SwimLane("lights")
+  JoinValueLane<String, Boolean> lights;
+}
+```
+
+Internally, lanes are always backed by `swim.structure.Value`s, regardless of their parametrized types. Under the hood, lanes use **forms** to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types provided that a form for that data type exists. Even custom Java classes can be lane types, provided that forms for those classes exist. We will further discuss this topic in a more advanced cookbook.
+
+<!-- Further reading: <a href="/reference/universal-addressability">Universal Addressability</a>, <a href="/reference/structures">Structures</a>
+-->
+
+### Instantiation and `didUpdate()`
+
+The `AbstractAgent` class comes with utility methods to construct runnable lanes. Recall, however, that developers rarely instantiate Web Agents by explicitly invoking their constructors. The recommended pattern for adding a value lane to an Agent is instead to:
+
+- Exclude constructors entirely from Web Agents
+- Use the `joinValueLane()` method to instantiate the lane; note that this is a parametrized method
+- Through a builder pattern, override the lane's `void didUpdate(K key, V newValue, V oldValue)` method
+
+This **didUpdate()** lifecycle callback is executed every time that a linked value lane gets its value updated, and it has access to the key of the updated value lane, the recently-updated value and its immediately prior one.
+
+```java
+// swim/basic/BuildingAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.JoinValueLane;
+
+public class BuildingAgent extends AbstractAgent {
+  @SwimLane("lights")
+  JoinValueLane<String, Boolean> lights = this.<String, Boolean>joinValueLane()
+                                              .didUpdate((String key,
+                                                          Boolean newValue,
+                                                          Boolean oldValue) -> {
+    System.out.println("The lights in room " + key + " are " + (newValue ? "off." : "on."));
+  });
+}
+```
+
+{% include alert.html title='Caution' text='If you have multiple lanes within an Agent type, ensure that their laneUris are not identical. Suppose we declare two different value lanes within our <strong>UnitAgent</strong> with laneUri <strong>"info"</strong>; how the Swim runtime know which one to set? That said, reusing laneUris <strong>across</strong> Agent types is perfectly acceptable, as requests corresponding to these are guaranteed to have different nodeUris.' %}
+
+### Aggregating value lanes
+
+In order to show how join value lanes can aggregate the value lanes of multiple agents, lets first create a new agent with a boolean value lane.
+
+```java
+// swim/basic/RoomAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.api.lane.ValueLane;
+import swim.structure.Value;
+
+public class RoomAgent extends AbstractAgent {
+  @SwimLane ("lights")
+  ValueLane<Boolean> lights = this.<Boolean>valueLane();
+
+  @Override
+  public void didStart() {
+    register();
+  }
+
+  @SwimLane ("toggleLights")
+  CommandLane<String> toggleLights = this.<String>commandLane().onCommand(msg -> {
+    this.lights.set(!lights.get());
+  });
+
+  private void register() {
+    String buildingUri = "/building/" + this.getProp("building").stringValue();
+    Value roomId = this.getProp("room");
+    command(buildingUri, "registerRoom", roomId);
+  }
+}
+```
+
+The **RoomAgent** represents a room in an office building, that has boolean flag to indicate whether the lights in the room are on. It has a toggle command lane, that can change the status of the lights.
+
+Additionally, it has a **register()** method, that is being called when an agent of type **RoomAgent** is first started. The method invokes the **registerRoom** command on the corresponding **BuildingAgent**, to which the room belongs.
+
+```java
+// swim/basic/BuildingAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.api.lane.JoinValueLane;
+import swim.structure.Value;
+
+public class BuildingAgent extends AbstractAgent {
+  @SwimLane ("lights")
+  JoinValueLane<String, Boolean> lights = this.<String, Boolean>joinValueLane()
+                                              .didUpdate((String key,
+                                                          Boolean newValue,
+                                                          Boolean oldValue) -> {
+    System.out.println("The lights in room " + key + " are " + (newValue ? "off." : "on."));
+  });
+
+  @SwimLane ("registerRoom")
+  CommandLane<Value> registerRoom = this.<Value>commandLane().onCommand(room -> {
+    String roomUri = "/" + this.getProp("name").stringValue() + "/" + room.stringValue();
+    this.lights.downlink(room.stringValue()).nodeUri(roomUri).laneUri("lights").open();
+  });
+}
+```
+
+The **registerRoom** command on the **BuildingAgent**, creates a permanent link to the **lights** value lane of the **RoomAgent** and adds the entry to the join value lane.
+
+### Reading from Join Value Lanes
+
+Map downlinks can be used in order to read the data from join value lanes. The following example shows how we can connect to the join value lane of the **BuildingAgent** and see the data from it.
+
+```java
+// swim/basic/CustomerClient.java
+package swim.basic;
+
+import swim.api.downlink.MapDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Form;
+
+class CustomClient {
+
+  public static void main(String[] args) throws InterruptedException {
+
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+    final String hostUri = "warp://localhost:9001";
+    final String buildingUri = "/building/swim";
+
+    final MapDownlink<Integer, Boolean> link = swimClient.downlinkMap()
+                                                        .keyForm(Form.forInteger())
+                                                        .valueForm(Form.forBoolean())
+                                                        .hostUri(hostUri)
+                                                        .nodeUri(buildingUri)
+                                                        .laneUri("lights")
+                                                        .open();
+
+    Thread.sleep(2000);
+    System.out.println("Join value lane");
+    link.get().forEach((key, value) -> System.out.println(key + ":" + value));
+
+
+    System.out.println("Will shut down client in 2 seconds");
+    Thread.sleep(2000);
+
+    swimClient.stop();
+  }
+}
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/join_map_lanes).
diff --git a/src/_rust_backend/lane-organization.md b/src/_rust_backend/lane-organization.md
new file mode 100644
index 0000000..941b4d6
--- /dev/null
+++ b/src/_rust_backend/lane-organization.md
@@ -0,0 +1,174 @@
+---
+title: Lane Organization
+short-title: Lane Organization
+description: Best practices for lane organization
+group: Getting Started
+layout: documentation
+redirect_from:
+  - /rust/concepts/lane-organization.html
+---
+
+Lanes expose an API for agents, allowing the state of an agent to be downlinked and streamed.
+Good lane organization allows for desired state to be viewed with as few downlinks and redundant data as possible.
+
+In this guide we will discuss the different lane types, what should be stored in them and how to organize them.
+
+## Value Lanes
+
+_For more details on usage and syntax see the [Value Lanes reference]({% link _rust_backend/value-lanes.md %})._
+
+Value lanes are the simplest form of a lane as they store flat data, a single **scalar value**.
+While this may seem limiting, remember that the scalar value can be an object with multiple fields, we commonly use the `Value` type as it is general purpose and all lanes are backed by it.
+If the data has a strict structure, consider strongly typing the lanes, see [Forms]({% link _rust_backend/forms.md %}).
+
+Value lanes should be organized into groups of highly related data.
+Frequency of change should also be considered, it is not efficient to send fields that rarely update with every state change of the agent.
+
+Avoid storing individual fields (a string, boolean, int) in a value lane, a single field is often not sufficient to build anything meaningful downstream and so another downlink will likely need to be opened.
+For example, street can be included in address, address in contact details, contact details in user info.
+
+At the other extreme, you should also avoid storing the entirety of an agent's state in a single value lane.
+Every subscription (i.e. downlink) to a value lane _at minimum_ transfers each new value to the lane (backpressure regulation aside).
+If your agent design stores `n` attributes in a single value lane, updates to a single attribute force downlinks to transfer the entire collection, leading to unnecessarily large message sizes for larger values of `n`.
+
+**Example**
+
+Let's say we have an agent representing something with a geographic location that can move (car, ship, plane).
+
+- The **status** lane will store current values of sensors, metrics and kpis (speed, altitude, fuel, ETA).
+  Current status fields change frequently and so this lane allows for real time insights into the agents performance.
+
+- The **info** lane will store some metadata about the agent (ID, model number, make, brand).
+  Metadata about the agent does not change frequently and so while it should still be available, we do not need to receive it with every state change, hence we separate it from the 'status' lane.
+
+- The **geo** lane will store key fields for rendering the agent on a map GUI (longitude, latitude, ID, colour).
+  This lane is specifically created for a component downstream, a map of all the agents.
+  The map only updates when an agent moves, and so we cherry-pick the fields the map requires to expose a bespoke lane.
+
+```java
+@SwimLane("status")
+public ValueLane<Value> status = this.<Value>valueLane();
+
+@SwimLane("info")
+public ValueLane<Value> info = this.<Value>valueLane();
+
+@SwimLane("geo")
+public ValueLane<Value> geo = this.<Value>valueLane();
+```
+
+## Map Lanes
+
+_For more details on usage and syntax see the [Map Lanes reference]({% link _rust_backend/map-lanes.md %})._
+
+Map Lanes store **collections** of data ordered by a **unique key** (key-value pairs), hence it is a little more intuitive what to store in map lanes.
+
+When one data point is updated, only the state change for that key-value pair (not the whole map) is streamed to downlinks, hence it is more efficient than storing all the data in a single value lane.
+
+**Example**
+
+Some examples of keyed data that can be stored in a map lane include:
+
+- Data with **IDs** (customer ID, order ID, vehicle ID)
+
+- Data with **unique names** ('Meeting Room 1', username, email)
+
+- **Timestamped** data (logs, history)
+
+- **Ordered** data where a unique key can be created ('Destination 1, 2, ...')
+
+```java
+@SwimLane("sensors")
+public MapLane<String, Value> sensors = this.<String, Value>mapLane();
+
+@SwimLane("log")
+public MapLane<Long, String> log = this.<Long, String>mapLane();
+
+@SwimLane("schedule")
+public MapLane<Integer, String> schedule = this.<Integer, String>mapLane();
+```
+
+## Join Value Lanes
+
+_For more details on usage and syntax see the [Join Value Lanes reference]({% link _rust_backend/join-value-lanes.md %})._
+
+Join value lanes are lanes that **aggregate** value lanes of other agents using downlinks, creating **one-to-many relationships** between agents.
+They essentially create a map lane, the key being some unique identifier of an agent (node URI being the obvious candidate), the value being the current value of another agent's value lane.
+The map can also be used to calculate aggregate metrics across the whole set of child agents.
+
+For a guide on how to implement an aggregate agent see the [aggregations guide]({% link _rust_backend/aggregations.md %}).
+
+**Example**
+
+Let's say we have a vehicle agent of some kind (a ship), that has a crew and is delivering orders of some kind.
+Each crew member and order has a corresponding agent, each with some kind of summary lane.
+Join value lanes will give us access to a single map for all crew or all orders, a single endpoint for all child agents of the aggregate agent.
+Aggregations across the whole set can now be performed, such as number of crew or total value of all orders on board.
+
+```java
+@SwimLane("crew")
+protected JoinValueLane<Value, Value> crew = this.<Value, Value>joinValueLane();
+
+@SwimLane("orders")
+protected JoinValueLane<Value, Value> orders = this.<Value, Value>joinValueLane();
+```
+
+## Demand Value Lanes
+
+_For more details on usage and syntax see the [Demand Value Lanes reference]({% link _rust_backend/demand-value-lanes.md %})._
+
+A demand value lane does not store a value, instead they are backed by a value lane and retrieve the value purely **on demand**.
+Demand value lanes **lazily generate events** for the value lane, only when there is an uplink ready to receive the event.
+
+Consider using a demand value lane if the input value of an agent requires significant processing or transformation before being stored in a value lane.
+In this case, storing the input value in a value lane and performing the transformation in a demand value lane can reduce unnecessary processing and the memory footprint of the agent.
+
+**Example**
+
+Let's say we have a 'compressed' value lane that stores some compressed data.
+We want to be able to downlink a lane that will stream uncompressed values for use downstream.
+We could decompress every value and store it in a new value lane but this would lead unnecessary processing and memory usage.
+The solution is to create a demand value lane that on demand will decompress the 'compressed' lane.
+
+```java
+@SwimLane("compressed")
+public ValueLane<String> compressed = this.<String>valueLane().didSet((n, o) -> this.data.cue());
+
+@SwimLane("data")
+public DemandLane<String> data = this.<String>demandLane().onCue(uplink -> uncompress());
+```
+
+## Demand Map Lanes
+
+_For more details on usage and syntax see the [Demand Map Lanes reference]({% link _rust_backend/demand-map-lanes.md %})._
+
+A demand map lane does not store a collection, instead they are backed by a map lane and retrieve values purely **on demand**.
+Demand map lanes **lazily generate events** for the map lane, only when there is an uplink ready to receive the event.
+
+Consider using a demand map lane if the input value of an agent requires significant processing or transformation before being stored in a map lane.
+In this case, storing the input value in a map lane and performing the transformation in a demand map lane can reduce unnecessary processing and the memory footprint of the agent.
+
+Demand map lanes also have access to the query parameters of the uplink it is serving.
+This enables on demand querying of map lanes, therefore also consider a demand map lane if it is likely that downlinks of a map lane only require events for a subset of the records.
+
+**Example**
+
+Let's say we have an agent with a 'user' map lane storing user metrics against username.
+In the application it is common to want to downlink a single user's metrics, receiving events for every user is far too many messages and wastes bandwidth.
+The solution is to create a demand map lane that on demand will filter events from the 'users' map lane.
+
+```java
+@SwimLane("users")
+public MapLane<String, Value> users = this.<String, Value>mapLane()
+
+@SwimLane("usersQuery")
+public DemandMapLane<String, Value> usersQuery = this.<String, Value>demandMapLane()
+    .onCue((key, uplink) -> {
+        final String username = uplink.laneUri().query().get("username");
+        return (key.equals(username)) ? this.users.get(username) : null;
+    })
+    .onSync(uplink -> {
+        final String username = uplink.laneUri().query().get("username");
+        return (this.users.containsKey(username)) ?
+            Collections.singletonList(username).iterator() : Collections.emptyIterator();
+    });
+```
diff --git a/src/_rust_backend/lanes.md b/src/_rust_backend/lanes.md
new file mode 100644
index 0000000..a1bfdbc
--- /dev/null
+++ b/src/_rust_backend/lanes.md
@@ -0,0 +1,54 @@
+---
+title: Lanes
+short-title: Lanes
+description: "Store state in Web Agents and trigger actions on Web Agents using Lanes"
+group: Reference
+layout: documentation
+redirect_from:
+  - /rust/concepts/lanes/
+  - /rust/reference/lanes.html
+---
+
+Distributed objects aren't very useful without properties to store state, and methods to trigger actions. Enter **lanes**. Each Web Agent has a set of named lanes, representing the properties and methods of the Web Agent.
+
+Lanes come in several varieties, corresponding to common data structures and access patterns. Apply ordinary principles of object-oriented design when designed Web Agent models, and their accompanying lanes.
+
+Compare a simple Web Agent, like the following:
+
+```java
+@SwimRoute("/person/:id")
+class PersonalAgent extends AbstractAgent {
+  @SwimLane
+  ValueLane<String> name;
+
+  @SwimLane
+  ValueLane<Profile> profile;
+
+  @SwimLane
+  JoinValueLane<String, Profile> friends;
+
+  @SwimLane
+  CommandLane<FriendRequest> befriend = this.<FriendRequest>commandLane()
+      .onCommand((friendRequest) => /* ... */);
+}
+```
+
+To its Plain Old Java Object counterpart:
+
+```java
+class Person {
+  String name;
+
+  Profile profile;
+
+  Map<String, Profile> friends;
+
+  public void befriend(FriendRequest friendRequest) {
+    /* ... */
+  }
+}
+```
+
+Not much difference. But the former instantiates distributable, automatically persistent, continuously consistent Web Agents, accessible via multiplexed streaming APIs. And the latter instantiates ephemeral Java objects.
+
+Jump ahead to [links]({% link _rust_backend/links.md %}) to find out more about streaming APIs. Dive into the [tutorials]({% link _rust_tutorials/index.md %}) to see how lanes are used in practice. Or read on to learn more about the various kinds of lanes available in Swim.
diff --git a/src/_rust_backend/links.md b/src/_rust_backend/links.md
new file mode 100644
index 0000000..c7f9266
--- /dev/null
+++ b/src/_rust_backend/links.md
@@ -0,0 +1,55 @@
+---
+title: Links
+short-title: Links
+description: "Learn how downlinks form references to the state of Web Agents."
+group: Reference
+layout: documentation
+redirect_from:
+  - /rust/concepts/links/
+  - /rust/reference/links.html
+---
+
+Central to programming is the ability to create pointers, or references, to things. Pointers are much more than memory addresses. Pointers often represent usage restrictions (think `const`, or `volatile`). And modern CPUs even use pointers as caching hints, pre-fetching data that might eventually be used in a computation. Swim takes the idea of pointers to the next level, enabling streaming references to the lanes of remote Web Agents, with strong consistency guarantees.
+
+Native machine pointers also trigger transparent message passing between CPU cores on a computer's memory bus, to keep the machine's memory model in a consistent state. Similarly, links between Web Agents trigger transparent message passing between networked machines to keep Swim's distributed memory model consistent.
+
+Links unify edges in an object graph, pointers in a cache coherency system, and subscriptions to mesaging topics, into a single, ultra high performance, easy to use programming primitive.
+
+Links are bidirectional. Either end of a link can update its implicitly shared state in an eventually consistent manner. A link has a downlink side, and an uplink side. The **downlink** side is the one held by the endpoint that opened the link. The **uplink** side is the one held by the endpoint that received the link request.
+
+To open a link, you create a downlink, and specify the address of the Web Agent (called the **node URI**), and the name of the lane (called the **lane URI**) to which you want to link. It's easier than it sounds. Here's what opening a link to a `ValueLane` looks like:
+
+```java
+const yourName = swim.downlinkValue()
+.node("warp://example.com/person/you")
+.lane("name")
+.open();
+```
+
+Once you open a link, Swim automatically handles maintaining a network connection to the appriate machine, and transparently shuffles messages back and forth to keep the link in sync with the state of the remote lane.
+
+Downlinks allow you to access a locally cached version of the remote lane's state, without blocking or waiting.
+
+```java
+console.log(yourName.get()); // prints your name
+```
+
+You can also set the state of a remote lane through a downlink.
+
+```java
+yourName.set("Yours Truly");
+```
+
+Conflicts are automatically resolved, and all links made eventually consistent. You can observe real-time state changes to remote lanes by registering callback functions on downlinks.
+
+```java
+yourName.didSet(name => console.log(`your name changed to ${name}`));
+```
+
+When you're no longer interested in the state of a remote lane, you can close a downlink to stop receiving updates.
+
+```java
+yourName.close();
+```
+
+Links are point-to-point, and unbuffered, making them real-time within the latency of the network and CPU. Dive into the [tutorials]({% link _rust_tutorials/index.md %}) to see how links get used in a real application. Or read on to learn more about the different kinds of links, their properties, and their guarantees.
diff --git a/src/_rust_backend/map-lanes.md b/src/_rust_backend/map-lanes.md
new file mode 100644
index 0000000..9f8299f
--- /dev/null
+++ b/src/_rust_backend/map-lanes.md
@@ -0,0 +1,214 @@
+---
+title: Map Lanes
+short-title: Map Lanes
+description: "Define persistent collection properties of Web Agents, and consistently stream real-time updates and removes."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/map_lanes
+redirect_from:
+  - /rust/tutorials/map-lanes/
+  - /rust/reference/map-lanes.html
+---
+
+In the [Web Agents guide]({% link _rust_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+
+Lanes come in many flavors, but every lane type exposes:
+
+- A **means to act** on the lane
+- Customizable **lifecycle callbacks** that execute during the runtime of the action
+- Various means to **strongly type** (i.e. **parametrize**) the lane
+- Universal WARP **subscriptions** to the lane
+
+A **map lane** stores a **keyed collection** of values, is sorted by key, and still meets these requirements:
+
+- Every map lane can have key, value pairs **put** into it and **remove**d from it. Additionally, several pairs can be **drop**ped at once
+- Doing so will trigger its **didUpdate()**, **didRemove()**, and **didDrop()** callbacks, respectively
+- The parameters on a map lane indicate the types of its keys and values
+- Map lane state and lifecycle can be subscribed to via both **map downlinks** and general-purpose **event downlinks**
+
+### Declaration
+
+All lanes are declared inside Web Agents as fields annotated with `@SwimLane`. The parameter inside this annotation is the lane's **laneUri**. Recall that every Web Agent has a universal, logical address known as its **nodeUri**; `laneUri`s are simply the equivalent counterpart for lanes.
+
+The following declaration is sufficient to make the `shoppingCart` lane of every `UnitAgent` addressable by the `laneUri` `"shoppingCart"`:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.MapLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("shoppingCart")
+  MapLane<String, Integer> shoppingCart;
+}
+```
+
+Internally, lanes are always backed by `swim.structure.Value`s, regardless of their parametrized types. Under the hood, lanes use `swim.structure.Form`s to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types provided that a form for that data type exists. Even custom Java classes can be lane types, provided that forms for those classes exist. We will further discuss this topic in a more advanced cookbook.
+
+<!-- Further reading: <a href="/reference/universal-addressability">Universal Addressability</a>, <a href="/reference/structures">Structures</a>
+-->
+
+### Instantiation and Callbacks
+
+The `AbstractAgent` class comes with utility methods to construct runnable lanes. Recall, however, that developers rarely instantiate Web Agents by explicitly invoking their constructors. The recommended pattern for adding a map lane to an Agent is instead to:
+
+- Exclude constructors entirely from Web Agents
+- Use the `mapLane()` method to instantiate the lane; note that this is a parametrized method
+- Through a builder pattern, override any of the lane's desired lifecycle callback methods:
+  - `void didUpdate(K key, V newValue, V oldValue)`: executed every time a key, value pair is placed in the lane
+  - `void didRemove(K key, V oldValue)`: executed every time a key is removed from the lane
+  - `void didDrop(int dropCount)`: executed every time `drop()` is invoked on the lane
+
+Should you define a constructor for your web agent, you must explicitly provide a default constructor and handle the initialization of all member variables declared by your Web Agent. However, it is not recommended to define any constructors. There is a `didStart()` lifecycle method that allows you to do post-initialization processing.
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.MapLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("shoppingCart")
+  MapLane<String, Integer> shoppingCart = this.<String, Integer>mapLane()
+      .didUpdate((key, newValue, oldValue) -> {
+        logMessage(key + " count changed to " + newValue + " from " + oldValue);
+      });
+
+  private void logMessage(Object msg) {
+    System.out.println(nodeUri() + ": " + msg);
+  }
+}
+```
+
+{% include alert.html title='Caution' text='If you have multiple lanes within an agent type, ensure that their <strong>laneUri</strong>s are not identical. Suppose we declare two different value lanes within our <strong>UnitAgent</strong> with laneUri <strong>"info"</strong>. How will the Swim runtime know which one to set? That said, reusing <strong>laneUri</strong>s **across** Agent types is perfectly acceptable, as requests corresponding to these are guaranteed to have different <strong>nodeUri</strong>s.' %}
+
+### External Addressability
+
+Lanes are Swim server endpoints; therefore, external processes must be able to access them directly. Just like accessing the `foo` field of an object `obj` in object-oriented paradigms requires both `obj` and `foo` in some way (e.g. `obj.foo`), addressing a lane requires both the `laneUri` and the `nodeUri` of its enclosing agent. Additionally, if the request comes from a different Swim runtime from where the target lane lives (i.e. an entirely different plane or a Swim client instance), then the request must also identify the **hostUri** on which the Swim server is running.
+
+Unlike with `command()` for command lanes, there is no general-purpose Swim API **method** to talk to map lanes (it's still possible, but we'll get to that in a bit). However, all lanes **within** an agent can directly reference each other in their callback functions. So, one common way to write to a map lane is to create a separate command lane whose `onCommand()` callback acts as a proxy:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.api.lane.MapLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("shoppingCart")
+  MapLane<String, Integer> shoppingCart = this.<String, Integer>mapLane()
+      .didUpdate((key, newValue, oldValue) -> {
+        logMessage(key + " count changed to " + newValue + " from " + oldValue);
+      });
+
+  @SwimLane("addItem")
+  CommandLane<String> publish = this.<String>commandLane()
+      .onCommand(msg -> {
+        final int n = this.shoppingCart.getOrDefault(msg, 0) + 1;
+        this.shoppingCart.put(msg, n);
+      });
+
+  private void logMessage(Object msg) {
+    System.out.println(nodeUri() + ": " + msg);
+  }
+}
+```
+
+Direct communication with value lanes is instead accomplished through **downlinks**. Downlinks are WARP subscriptions to lanes. They come in many flavors, but subscriptions to map lanes can only be accomplished through **map downlinks** and, to a more limited extent, **event downlinks**.
+
+Further reading: [Command Lanes]({% link _rust_backend/command-lanes.md %}), [Downlinks]({% link _rust_backend/downlinks.md %})
+
+### Writing to Map Lanes
+
+Map downlinks can be instantiated using the `downlinkMap()` method from any Swim handle, as long as the desired hostUri (optional if the target lane is within the same Swim handle), nodeUri, and laneUri are known in advance. Once a map downlink is initialized, `put()`, `remove()`, and `drop()` can be directly invoked on it, as if it were the underlying lane itself.
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.api.downlink.MapDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Form;
+import swim.structure.Text;
+import swim.structure.Value;
+
+class CustomClient {
+  public static void main(String[] args) throws InterruptedException {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+    final String hostUri = "warp://localhost:9001";
+    final String nodeUri = "/unit/master";
+    swimClient.command(hostUri, nodeUri, "WAKEUP", Value.absent());
+    // Send using either the proxy command lane...
+    swimClient.command(hostUri, nodeUri, "addItem", Text.from("FromClientCommand"));
+    // ...or a downlink put()
+    final MapDownlink<String, Integer> link = swimClient.downlinkMap()
+        .keyForm(Form.forString()).valueForm(Form.forInteger())
+        .hostUri(hostUri).nodeUri(nodeUri).laneUri("shoppingCart")
+        .open();
+    link.put("FromClientLink", 25);
+    link.remove("FromClientLink");
+
+    System.out.println("Will shut down client in 2 seconds");
+    Thread.sleep(2000);
+    swimClient.stop();
+  }
+}
+```
+
+### Reading from Map Lanes
+
+There are two ways to read data from map lanes, both of which require opening a downlink.
+
+The simpler approach is to simply call `get(K key)` on the downlink to read its value at `key` at the time of the invocation.
+
+The far more powerful approach uses the fact that map downlinks **also** have access to `didUpdate()`. This enables an event-driven style of programming where client programs are treated as completely in sync with the server. And, excluding network latency and backpressure regulation of network packets, they basically are.
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.api.downlink.MapDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Form;
+import swim.structure.Text;
+import swim.structure.Value;
+
+class CustomClient {
+  public static void main(String[] args) throws InterruptedException {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+    final String hostUri = "warp://localhost:9001";
+    final String nodeUri = "/unit/master";
+    swimClient.command(hostUri, nodeUri, "WAKEUP", Value.absent());
+    final MapDownlink<String, Integer> link = swimClient.downlinkMap()
+        .keyForm(Form.forString()).valueForm(Form.forInteger())
+        .hostUri(hostUri).nodeUri(nodeUri).laneUri("shoppingCart")
+        .didUpdate((key, newValue, oldValue) -> {
+          System.out.println("link watched " + key + " change to " + newValue + " from " + oldValue);
+        })
+        .open();
+    // Send using either the proxy command lane...
+    swimClient.command(hostUri, nodeUri, "addItem", Text.from("FromClientCommand"));
+    // ...or a downlink put()
+    link.put("FromClientLink", 25);
+    link.remove("FromClientLink");
+
+    System.out.println("Will shut down client in 2 seconds");
+    Thread.sleep(2000);
+    swimClient.stop();
+  }
+}
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/map_lanes).
diff --git a/src/_rust_backend/persistence.md b/src/_rust_backend/persistence.md
new file mode 100644
index 0000000..422249c
--- /dev/null
+++ b/src/_rust_backend/persistence.md
@@ -0,0 +1,11 @@
+---
+title: Persistence
+short-title: Persistence
+description: "Learn about Web Agent Persistence"
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/persistence
+redirect_from:
+  - /rust/tutorials/Persistence/
+  - /rust/reference/Persistence.html
+---
diff --git a/src/_rust_backend/planes.md b/src/_rust_backend/planes.md
new file mode 100644
index 0000000..d3409a5
--- /dev/null
+++ b/src/_rust_backend/planes.md
@@ -0,0 +1,272 @@
+---
+title: Planes
+short-title: Planes
+description: "Create vertically integrated, horizontally distributed Web Agent application bundles that can run almost anywhere."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/planes
+redirect_from:
+  - /rust/tutorials/planes/
+  - /rust/reference/planes.html
+---
+
+In the [Web Agents guide]({% link _rust_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects** and **lanes** are **fields**. Swim **planes** can, loosely, be seen as a **shared context** for a group of Web Agents, somewhat analogous to **scopes** but with more runtime responsibilities.
+
+More specifically, every plane:
+
+- Routes messages, both within and from outside its containing process, to the correct Web Agents and lanes
+- Has lifecycle callback functions that are overridable with custom logic
+- Is itself a Swim handle and can therefore talk to any other Swim handle over WARP
+- Can define security policies to control access to Swim data
+
+### Declaration
+
+Simply create a custom class that extends `swim.api.plane.AbstractPlane` to declare a plane:
+
+```java
+// swim/basic/BasicPlane.java
+package swim.basic;
+
+import swim.api.plane.AbstractPlane;
+
+public class BasicPlane extends AbstractPlane {
+}
+```
+
+However, a typical pattern with Swim planes is to additionally solve the routing responsibility within the declaration. Much like lanes in a Web Agent are annotated with `@SwimLane`, each Agent type in a plane should be annotated with `@SwimRoute`. The argument inside the annotation defines a URI **pattern** (colons (:) indicate dynamic components). Requests that match this pattern are routed to an Agent of the provided type, with instantiations happening as necessary:
+
+```java
+// swim/basic/BasicPlane.java
+package swim.basic;
+
+import swim.api.agent.AgentRoute;
+import swim.api.SwimRoute;
+import swim.api.plane.AbstractPlane;
+
+public class BasicPlane extends AbstractPlane {
+  @SwimRoute("/unit/:id")
+  AgentRoute<UnitAgent> unitAgentType;
+}
+```
+
+### Instantiation
+
+Somewhat similarly to Web Agents, planes are not typically instantiated using their constructors. Planes don't make much sense outside a Swim server, so we will piggyback off server initialization itself to instantiate planes.
+
+Recall that Swim servers can be loaded from a configuration file. Take note of how we define which plane this server will load:
+
+```java
+# /server.recon
+basic: @fabric {
+  @plane(class: "swim.basic.BasicPlane")
+}
+
+@web(port: 9001) {
+  space: "basic"
+  documentRoot: "./ui/"
+  @websocket {
+    serverCompressionLevel: 0# -1 = default; 0 = off; 1-9 = deflate level
+    clientCompressionLevel: 0# -1 = default; 0 = off; 1-9 = deflate level
+  }
+}
+```
+
+Swim provides a utility class, `swim.loader.ServerLoader`, to facilitate the actual load step:
+
+```java
+// swim/basic/BasicPlane.java
+package swim.basic;
+
+import swim.api.agent.AgentRoute;
+import swim.api.SwimRoute;
+import swim.api.plane.AbstractPlane;
+import swim.kernel.Kernel;
+import swim.server.ServerLoader;
+
+public class BasicPlane extends AbstractPlane {
+  @SwimRoute("/unit/:id")
+  AgentRoute<UnitAgent> unitAgentType;
+
+  // main() can be in any class, we picked this for convenience
+  public static void main(String[] args) {
+    final Kernel kernel = ServerLoader.loadServer();
+    kernel.start();
+    kernel.run();
+  }
+}
+```
+
+### Lifecycle Callbacks
+
+Just like Web Agents and lanes, planes come with callback functions that are executed during various stages of their lifecycle, and the callbacks are overridable with custom logic. The two that you are most likely to care about are **didStart()** and **willStop()**, which work similarly to their Web Agent counterparts:
+
+```java
+// swim/basic/BasicPlane.java
+package swim.basic;
+
+import swim.api.agent.AgentRoute;
+import swim.api.SwimRoute;
+import swim.api.plane.AbstractPlane;
+import swim.structure.Value;
+import swim.kernel.Kernel;
+import swim.server.ServerLoader;
+
+
+public class BasicPlane extends AbstractPlane {
+  @SwimRoute("/unit/:id")
+  AgentRoute<UnitAgent> unitAgentType;
+
+  @Override
+  public void didStart() {
+    command("/unit/master", "WAKEUP", Value.absent());
+  }
+
+  @Override
+  public void willStop() {
+    System.out.println("Shutdown in progress...");
+  }
+
+  public static void main(String[] args) {
+    final Kernel kernel = ServerLoader.loadServer();
+    kernel.start();
+    kernel.run();
+  }
+}
+```
+
+### Planes Are Swim Handles
+
+In the previous snippet, we called `command()` from directly within our custom plane class. By themselves being Swim handles, planes have access to the Swim API.
+
+Recall that a Swim server runs asynchronously relative to the main thread that started it, implying that the main thread is free to do work. We demonstrate here how one could use a plane (context) as a Swim handle. Note especially how a simple one-argument difference enables users to go through the network stack and talk to a remote process (we resolve to the same one here to avoid forcing you to start a new process):
+
+```java
+// swim/basic/BasicPlane.java
+package swim.basic;
+
+import swim.api.agent.AgentRoute;
+import swim.api.SwimRoute;
+import swim.api.plane.AbstractPlane;
+import swim.structure.Value;
+import swim.fabric.Fabric;
+import swim.structure.Text;
+import swim.kernel.Kernel;
+import swim.server.ServerLoader;
+
+public class BasicPlane extends AbstractPlane {
+  @SwimRoute("/unit/:id")
+  AgentRoute<UnitAgent> unitAgentType;
+
+  @Override
+  public void didStart() {
+    command("/unit/master", "WAKEUP", Value.absent());
+  }
+
+  @Override
+  public void willStop() {
+    System.out.println("Shutdown in progress...");
+  }
+
+  public static void main(String[] args) {
+    final Kernel kernel = ServerLoader.loadServer();
+    kernel.start();
+    final Fabric fabric = (Fabric) kernel.getSpace("basic");
+    kernel.run();
+    // observe the effects of our commands
+    fabric.downlinkValue()
+      .nodeUri("/unit/master")
+      .laneUri("info")
+      .didSet((newValue, oldValue) -> {
+        System.out.println("observed info change to " + newValue + " from " + oldValue);
+      })
+      .open();
+    fabric.command("/unit/master", "publishInfo", Text.from("Without network"));
+    fabric.command("warp://localhost:9001", "/unit/master", "publishInfo", Text.from("With network, no token"));
+    fabric.command("warp://localhost:9001?token=abcd", "/unit/master", "publishInfo", Text.from("With network, no token"));
+  }
+}
+```
+
+### Security Policies
+
+Security policies can be defined to control client access to a plane. Simply define a custom policy, then inject it into your custom plane upon its initialization.
+
+We will go into more detail about security policies in a later section. In the meantime, the snippet is how one would enhance our custom plane to only accept requests containing the right token as a URL parameter. While not a best practice, it demonstrates the general pattern for injecting policies into planes:
+
+```java
+// swim/basic/BasicPlane.java
+package swim.basic;
+
+import swim.api.agent.AgentRoute;
+import swim.api.auth.Identity;
+import swim.api.SwimRoute;
+import swim.api.plane.AbstractPlane;
+import swim.api.policy.AbstractPolicy;
+import swim.api.policy.PolicyDirective;
+import swim.fabric.Fabric;
+import swim.kernel.Kernel;
+import swim.server.ServerLoader;
+import swim.structure.Text;
+import swim.structure.Value;
+import swim.warp.Envelope;
+
+public class BasicPlane extends AbstractPlane {
+  // Define policy; doesn't have to be an inner class
+  class BasicPolicy extends AbstractPolicy {
+    @Override
+    protected <T> PolicyDirective<T> authorize(Envelope envelope, Identity identity) {
+      if (identity != null) {
+        final String token = identity.requestUri().query().get("token");
+        if ("abcd".equals(token)) {
+          return allow();
+        }
+      }
+      return forbid();
+    }
+  }
+
+  @SwimRoute("/unit/:id")
+  AgentRoute<UnitAgent> unitAgentType;
+
+  // Inject policy. Swim internally calls the no-argument constructor, which retains
+  // its implicit call to super() in Java
+  public BasicPlane() {
+    context.setPolicy(new BasicPolicy());
+  }
+
+  @Override
+  public void didStart() {
+    command("/unit/master", "WAKEUP", Value.absent());
+  }
+
+  @Override
+  public void willStop() {
+    System.out.println("Shutdown in progress...");
+  }
+
+  public static void main(String[] args) {
+    final Kernel kernel = ServerLoader.loadServer();
+    kernel.start();
+    final Fabric fabric = (Fabric) kernel.getSpace("basic");
+    kernel.run();
+    // observe the effects of our commands
+    fabric.downlinkValue()
+      .nodeUri("/unit/master")
+      .laneUri("info")
+      .didSet((newValue, oldValue) -> {
+        System.out.println("observed info change to " + newValue + " from " + oldValue);
+      })
+      .open();
+    // Swim handles don't reject their own messages, regardless of policy
+    fabric.command("/unit/master", "publishInfo", Text.from("Without network"));
+    // Network events without tokens get rejected
+    fabric.command("warp://localhost:9001", "/unit/master", "publishInfo", Text.from("With network, no token"));
+    // Network events with the right token are accepted
+    fabric.command("warp://localhost:9001?token=abcd", "/unit/master", "publishInfo", Text.from("With network, token"));
+  }
+}
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/planes).
diff --git a/src/_rust_backend/server-downlinks.md b/src/_rust_backend/server-downlinks.md
new file mode 100644
index 0000000..dedf5ff
--- /dev/null
+++ b/src/_rust_backend/server-downlinks.md
@@ -0,0 +1,132 @@
+---
+title: Server Downlinks
+short-title: Server Downlinks
+description: "Share data across Web Agents and servers through persistent, bidirectionally-streaming lane references."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/server_downlinks
+redirect_from:
+  - /rust/tutorials/server-downlinks/
+  - /rust/reference/server-downlinks.html
+---
+
+In the [Downlinks guide]({% link _rust_backend/downlinks.md %}), we discuss **downlinks** - bidirectionally-streaming, persistent **subscriptions** to lanes - and went through an example of a client-side downlink. This guide will showcase downlinks between two Swim servers.
+
+Server-side downlinks provide a simple and efficient way to integrate Swim applications allowing them to be linked or chained together with ease.
+
+There are two big things to manage when dealing with downlinks: **data** and **connections**. This guide will focus heavily on the former; we will expand on connection management in a future, more advanced article.
+
+### Declaration
+
+#### Java
+
+All downlink classes can be imported from package `swim.api.downlink`.
+
+### Usage
+
+Downlinks must be instantiated against Swim refs, i.e. specific server-side or client-side objects. Although several permutations exist, the builder pattern is the same each time:
+
+1. Invoke `downlink()` against your ref for an event downlink, or `downlinkFoo()` for a foo downlink (e.g. `downlinkMap()` for a map downlink)
+1. Build the downlink's `hostUri` using `hostUri()` (this step can only be omitted if your Swim ref is server-side, and you are targeting a lane within the same server), the downlink's `nodeUri` using `nodeUri()`, and the downlink's `laneUri` using `laneUri()`
+1. Override any lifecycle callback functions, which default to no-ops
+1. In strongly-typed languages (Java, Typescript), optionally parametrize the downlink
+1. Optionally set the **keepSynced** (pull all existing data from a lane before processing new updates; defaults to `false`) and **keepLinked** (enable consistent **reads** from the downlink (unnecessary for write-only downlinks); defaults to `true`) flags
+1. Invoke `open()` on the downlink to initiate data flow
+1. When finished, invoke `close()` on the downlink to stop data flow
+
+#### Lifecycle callbacks and updating lanes
+
+Every event downlink has a customizable `onEvent(V event)` callback function that specifies the action to take upon every event received by the target lane.
+
+For all other (i.e. lane-specific) downlinks, recall that every data-storing lane can be acted upon by methods specific to that lane type (e.g. `set` for value lanes; `put`, `remove`, `drop`, `take`, and `clear` for map lanes). These options also exist on correctly-configured lane-specific downlinks. Furthermore, for every such method `foo`, each downlink has a `didFoo(Object... args)` method that follows similar lifecycle semantics to `onEvent()`, but with more useful callback parameters. For example, every `MapDownlink<K, V>` has access to `didUpdate(K key, V newValue, V oldValue)`, `didRemove(K key, V oldValue)`, `didDrop(int dropCount)`, `didTake(int keepCount)`, and `didClear()` methods.
+
+#### Parametrization
+
+Unlike with lanes, which additionally offer parametrized methods, downlink parametrization **requires** providing ``swim.structure.Forms` through a builder pattern.
+
+#### Java
+
+Server-side, downlinks can be issued either against plane contexts:
+
+```java
+// swim/basic/SupplierPlane
+package swim.basic;
+
+import swim.actor.ActorSpace;
+import swim.api.SwimRoute;
+import swim.api.agent.AgentRoute;
+import swim.api.plane.AbstractPlane;
+import swim.kernel.Kernel;
+import swim.server.ServerLoader;
+import swim.structure.Form;
+
+public class SupplierPlane extends AbstractPlane {
+
+  public final static String WAREHOUSE_HOST_URI = "warp://localhost:9001";
+
+  @SwimRoute("/supplier")
+  AgentRoute<SupplierAgent> supplierAgentType;
+
+  @SwimRoute("/customer/:id")
+  AgentRoute<CustomerAgent> customerAgentType;
+
+  public static void main(String[] args) {
+    final Kernel kernel = ServerLoader.loadServerStack();
+    final ActorSpace plane = (ActorSpace) kernel.getSpace("supplier");
+
+    kernel.start();
+
+    //Create a value downlink to a different Swim server directly from this plane
+    plane.downlinkValue()
+        .valueForm(Form.forInteger())
+        .hostUri(WAREHOUSE_HOST_URI)
+        .nodeUri("/warehouse/cambridge").laneUri("lastResupplyId")
+        .didSet((newValue, oldValue) -> {
+          logMessage("latest supply id received at warehouse: " + newValue);
+        }).open();
+  }
+}
+```
+
+or against Agent contexts using the `AbstractAgent.downlinkFoo()` methods, both as fields within Agents, and as local variables within methods (latter demonstrated here):
+
+```java
+// swim/basic/CustomerAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.structure.Form;
+import swim.structure.Text;
+
+import java.util.Objects;
+
+public class CustomerAgent extends AbstractAgent {
+
+  @SwimLane("register")
+  public CommandLane<String> register = this.<String>commandLane()
+      .onCommand(location -> {
+        addStockNotificationDownlink(location);
+      });
+
+  private void addStockNotificationDownlink(final String location) {
+    final String warehouseNodeUri = "/warehouse/" + location;
+
+    //Create a value downlink to a different Swim server from an agent
+    this.downlinkValue().valueForm(Form.forInteger())
+        .hostUri(SupplierPlane.WAREHOUSE_HOST_URI)
+        .nodeUri(warehouseNodeUri).laneUri("lastResupplyId")
+        .didSet((newValue, oldValue) -> {
+          if (!Objects.equals(newValue, oldValue))
+            logMessage("customer received new stock notification, resupply: " + newValue);
+          }).open();
+  }
+}
+```
+
+Client-side downlinks have been showcased in the [Downlinks guide]({% link _rust_backend/downlinks.md %}).
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/server_downlinks).
diff --git a/src/_rust_backend/server.md b/src/_rust_backend/server.md
new file mode 100644
index 0000000..7d408dd
--- /dev/null
+++ b/src/_rust_backend/server.md
@@ -0,0 +1,10 @@
+---
+title: Server
+short-title: Web Agents
+description: "Learn about using the Swim Server"
+group: Reference
+layout: documentation
+redirect_from:
+  - /rust/tutorials/server/
+  - /rust/reference/server.html
+---
diff --git a/src/_rust_backend/summary-statistics.md b/src/_rust_backend/summary-statistics.md
new file mode 100644
index 0000000..9100041
--- /dev/null
+++ b/src/_rust_backend/summary-statistics.md
@@ -0,0 +1,334 @@
+---
+title: Summary Statistics
+short-title: Summary Statistics
+description: "How to abridge a Web Agent's history into summary statistics"
+group: Swim Apps
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/summary_statistics
+redirect_from:
+  - /rust/guides/summary-statistics.html
+---
+
+Real-time applications frequently need to produce summaries of ingested data.
+An especially common requirement is producing multiple reports, one per entity within a system being monitored.
+
+This guide illustrates how to solve problems of this nature by using Swim to:
+
+- Model each entity of interest within the system as a Web Agent
+- Within Web Agents, efficiently compute statistics against ingested data
+- Expose the results in granular streaming APIs.
+
+## Representation
+
+Suppose we wish to monitor the health of multiple cell towers that continuously post their current state.
+Each update might look like (JSON):
+
+```
+{
+  "tower_id": (unique identifier)
+  "timestamp": (epoch in ms),
+  "s_n_ratio": (signal-noise ratio),
+  "disconnects": (failures since previous posted update)
+  ... (possibly more fields)
+}
+```
+
+Each tower requires a corresponding Web Agent that can receive and process these updates. A skeletal `AbstractTowerAgent` class could look like:
+
+```java
+// AbstractTowerAgent.java
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.structure.Value;
+
+public abstract class AbstractTowerAgent extends AbstractAgent {
+
+  @SwimLane("addMessage")
+  CommandLane<Value> addMessage = this.<Value>commandLane()
+      .onCommand(v -> updateSummary(messageTimestamp(v), v));
+
+  protected long messageTimestamp(Value v) {
+    return v.get("timestamp").longValue();
+  }
+
+  protected abstract void updateSummary(long timestamp, Value newValue);
+
+}
+```
+
+## Stream-Optimized Algorithms
+
+Efficiency is critical if we call `updateSummary()` against every incoming message, especially if message volumes are high.
+Running [offline algorithms](https://en.wikipedia.org/wiki/Online_algorithm) against a [time series]({% link _rust_backend/time-series.md %}) that contains every received message can compute _any_ (solvable) statistic of interest, but this approach incurs linearly increasing memory and time costs.
+
+Suppose that each `TowerAgent` must report:
+
+- the minimum, maxium, average, and variance (squared standard deviation) over all received `s_n_ratio` values
+- the sum over all received `disconnects` values
+
+We can accomplish this without ever reading a time series. Upon receiving a status update:
+
+- Updating the minimum and maximum only requires the old minimum and maximum (e.g. `newMin=min(oldMin, newVal)`)
+- Updating the average also only requires some state, perhaps (but not necessarily) the old running sum and the number of messages received (`newSum=oldSum+newVal; newCount+=1; newAvg=newSum/newCount`)
+- Updating the variance can be accomplished, perhaps surprisingly, by reading only three accumulated values using [Welford's online algorithm](https://en.wikipedia.org/wiki/Algorithms_for_calculating_variance#Welford's_online_algorithm)
+- Updating the sum only requires the old sum (`newSum=oldSum+newFailures`)
+
+For cleanliness, let's wrap functionality in a separate class:
+
+```java
+// TowerSummaryState.java
+import swim.structure.Record;
+import swim.structure.Value;
+
+class TowerSummaryState {
+
+  // sinr
+  private double min = Double.MAX_VALUE;
+  private double max = -Double.MIN_VALUE;
+  private int count = 0;
+  private double mean = 0.0;
+  private double agg = 0.0;
+  // failures
+  private int failures = 0;
+
+  public void addValue(double d, int f) {
+    this.min = Math.min(this.min, d);
+    this.max = Math.max(this.max, d);
+    this.count += 1;
+    // Welford's online algorithm for computing variance also handles mean.
+    // The mean part may seem cryptic. Start from the fact that:
+    //   newMean = (oldMean * (newCount - 1) + d) / newCount
+    // Now let delta = d - oldMean, and these two lines should make sense.
+    final double delta = d - this.mean;
+    this.mean += delta / this.count;
+    // delta is required to update Welford's algorithm's critical accumulator.
+    this.agg += delta * (d - this.mean);
+
+    this.failures += f;
+  }
+
+  public Value getSummary() {
+    if (this.count == 0) {
+      return Value.extant();
+    }
+    return Record.create(6)
+        .slot("count", this.count)
+        .slot("min", this.min)
+        .slot("max", this.max)
+        .slot("avg", this.mean)
+        .slot("variance", this.agg / this.count)
+        .slot("failures", this.failures);
+    // Note: agg and count trivially transform into more than just variance:
+    // - agg / count = variance
+    // - sqrt(agg/count) = stdev
+    // - agg / (count - 1) = sample variance
+    // - sqrt(agg / (count - 1)) = sample stdev
+  }
+
+}
+```
+
+_Note: The average could just as effectively have been calculated with a rolling sum divided by the count, as suggested earlier._
+_We only chose this approach because we require `delta` to calculate variance anyway._
+
+_Note: Not every statistic can be optimized this perfectly._
+_For example, any (non-heuristic) median over floating points will require reading past values at some point, leading to `O(n)` space complexity (choice of representation may still reduce time complexity)._
+
+This yields a very compact `TowerAgent` implementation:
+
+```java
+// TowerAgent.java
+import swim.api.lane.ValueLane;
+import swim.recon.Recon;
+import swim.structure.Value;
+
+public class TowerAgent extends AbstractTowerAgent {
+
+  private TowerSummaryState state;
+
+  @SwimLane("summary")
+  ValueLane<Value> summary = this.<Value>valueLane()
+      .didSet((n, o) ->
+          System.out.println(nodeUri() + ": updated summary to " + Recon.toString(n)));
+
+  @Override
+  protected void updateSummary(long timestamp, Value v) {
+    this.state.addValue(v.get("s_n_ratio").doubleValue(),
+        v.get("disconnects").intValue());
+    this.summary.set(this.state.getSummary());
+  }
+
+  @Override
+  public void didStart() {
+    this.state = new TowerSummaryState();
+  }
+
+}
+```
+
+_Note: While we discourage reliance on it for computations, we could easily attach a [time series]({% link _rust_backend/time-series.md %}) of message history to `TowerAgent` (or its variations described in the upcoming sections)._
+_Doing so instantiates two sets of streaming APIs: one for comprehensive statistics, and one for individual events._
+_This may be a valuable addition, especially when combined with a retention policy that retains only recent or interesting historical events._
+
+## Bucketed Summaries
+
+Currently, each `TowerAgent` computes a single summary over its entire lifetime.
+We can instead choose to track muliple summaries, each representing some subset of the entity's data.
+One common motivator for this is a need for _time-based bucketing_, i.e. separate summaries that each cover a non-overlapping time period (such as every 15 minutes).
+
+To support this functionality, simply update `TowerAgent` to 1) maintain a `Map` of `TowerSummaryStates` (as opposed to a single `TowerSummaryState`) 2) publish summaries to a `MapLane` instead of a `ValueLane`:
+
+```java
+// BucketedTowerAgent.java
+import java.util.HashMap;
+import java.util.Map;
+import swim.api.lane.MapLane;
+
+public class BucketedTowerAgent extends AbstractTowerAgent {
+
+  // one minute period so you can quickly test this yourself
+  private static final long SAMPLE_PERIOD_MS = 60000L;
+
+  // Each key to this HashMap is the top of the minute covered by the value.
+  // For example the TowerSummaryState for the left-inclusive time period
+  //   [2023-08-21 17:09:00, 2023-08-21 17:10:00) (in UTC)
+  // will be under the key 1692637740000L.
+  // Note that you could choose to expose this as a MapLane, too.
+  private Map<Long, TowerSummaryState> summaryStates;
+
+  // Same keys as the summaryStates map
+  @SwimLane("summaries")
+  MapLane<Long, Value> summaries = this.<Long, Value>mapLane()
+      .didUpdate((k, n, o) ->
+          System.out.println(nodeUri() + ": updated summary under " + k + " to " + Recon.toString(n)));
+
+  @Override
+  protected void updateSummary(long timestamp, Value v) {
+    final long key = bucket(timestamp);
+    final TowerSummaryState state = this.summaryStates.getOrDefault(key, new TowerSummaryState());
+    state.addValue(v.get("s_n_ratio").doubleValue(),
+        v.get("disconnects").intValue());
+    this.summaries.put(key, state.getSummary());
+    this.summaryStates.put(key, state);
+  }
+
+  private static long bucket(long timestamp) {
+    // Floor div then multiplication quickly purges non-significant digits.
+    // For example:
+    //   2023-08-21 17:09:34 = (in epoch milliseconds) 1692637774000
+    //   1692637774000 / 60000 = 28210629
+    //   28210629 * 60000 = 1692637740000
+    // which matches the value in the summaryStates field's comment.
+    // This strategy may not work as expected for awkward SAMPLE_PERIOD values;
+    // adjust as needed for your use case.
+    return timestamp / SAMPLE_PERIOD_MS * SAMPLE_PERIOD_MS;
+  }
+
+  @Override
+  public void didStart() {
+    if (this.summaryStates != null) {
+      this.summaryStates.clear();
+    }
+    this.summaryStates = new HashMap<>();
+  }
+
+}
+```
+
+## Windowed Summaries
+
+The logic in the previous section works even if messages come out of order, and if we receive a message whose timestamp is in the future.
+However, it requires maintaining multiple independent summary states at a time, since a new incoming message could target any one of these.
+
+An application that uses _system timestamps_ instead of message timestamps never encounters these situations.
+Consequently, it only needs one summary state accumulator; just make sure to reset it if time has elapsed into a new bucket.
+
+```java
+// WindowedTowerAgent.java
+public class WindowedTowerAgent extends AbstractTowerAgent {
+
+  private static final long SAMPLE_PERIOD_MS = 60000L;
+
+  private TowerSummaryState currentState;
+  private long currentBucket;
+
+  @SwimLane("summaries")
+  MapLane<Long, Value> summaries = this.<Long, Value>mapLane()
+      .didUpdate((k, n, o) ->
+          System.out.println(nodeUri() + ": updated summary under " + k + " to " + Recon.toString(n)));
+
+  @Override
+  protected long messageTimestamp(Value v) {
+    // Pretend v lacks time information, so our best option is system time
+    return System.currentTimeMillis();
+  }
+
+  @Override
+  protected void updateSummary(long timestamp, Value v) {
+    final long key = bucket(timestamp);
+    if (key != this.currentBucket) {
+      // Time has passed into a new bucket, reset accumulations
+      resetState(timestamp);
+    }
+    this.currentState.addValue(v.get("s_n_ratio").doubleValue(),
+        v.get("disconnects").intValue());
+    this.summaries.put(key, this.currentState.getSummary());
+  }
+
+  private void resetState(long now) {
+    this.currentState = new TowerSummaryState();
+    this.currentBucket = bucket(now);
+  }
+
+  private static long bucket(long timestamp) {
+    return timestamp / SAMPLE_PERIOD_MS * SAMPLE_PERIOD_MS;
+  }
+
+  @Override
+  public void didStart() {
+    resetState(System.currentTimeMillis());
+  }
+
+}
+```
+
+## Standalone Project
+
+We encourage you to experiment with the [standalone project](https://github.com/swimos/cookbook/tree/master/summary_statistics) that collects the information and code samples presented here.
+A few things to note:
+
+- Running the `Main` class runs both a Swim server _and_ a simulator that feeds with data.
+- `src/main/resources/server.recon` defines routing that activates `TowerAgent`, `BucketedTowerAgent`, and `WindowedTowerAgent` all at once to facilitate exploration; in a real application, you would likely pick a single implementation.
+
+The following [`swim-cli`]({% link _rust_backend/cli.md %}) commands are available while the process runs (replace `$ID` instances with either `2350` or `2171`):
+
+- Subscribing to a `TowerAgent` instance's `summary` lane
+
+  ```
+  % swim-cli sync -h warp://localhost:9001 -n /tower/$ID -l summary
+
+  {count:6,min:10.522381743242732,max:22.28527569332349,avg:17.403808512841756,variance:17.16435437538436,failures:1}
+  {count:7,min:10.522381743242732,max:23.042896596076552,avg:18.20939252473244,variance:18.6060973516128,failures:1}
+  {count:8,min:10.522381743242732,max:23.042896596076552,avg:17.689421621696006,variance:18.172923362692888,failures:3}
+  ...
+  ```
+
+- Subscribing to a `BucketedTowerAgent` instance's `summaries` lane
+
+  ```
+  % swim-cli sync -h warp://localhost:9001 -n /towerB/$ID -l summaries
+
+  @update(key:1692679380000){count:29,min:10.77128446925376,max:23.24959464873697,avg:16.2544517182087,variance:14.289407826056422,failures:13}
+  @update(key:1692679440000){count:30,min:13.118910710309262,max:25.28277927585947,avg:19.02977006553927,variance:12.15474919075009,failures:13}
+  @update(key:1692679500000){count:24,min:11.35274353757999,max:24.775153946326895,avg:18.213836505473765,variance:16.033697773471467,failures:12}
+  @update(key:1692679500000){count:25,min:11.35274353757999,max:24.775153946326895,avg:18.41973124051554,variance:16.409773268562738,failures:12}
+  ```
+
+- Subscribing to a `WindowedTowerAgent` instance's `summaries` lane
+
+  ```
+  % swim-cli sync -h warp://localhost:9001 -n /towerW/$ID -l summaries
+
+  (output similar to previous command)
+  ```
diff --git a/src/_rust_backend/swim-libraries.md b/src/_rust_backend/swim-libraries.md
new file mode 100644
index 0000000..75185df
--- /dev/null
+++ b/src/_rust_backend/swim-libraries.md
@@ -0,0 +1,68 @@
+---
+title: Swim Libraries
+short-title: Swim Libraries
+description: "Use SwimOS back-end and front-end components to build streaming data applications."
+group: Getting Started
+layout: documentation
+redirect_from:
+  - /rust/start/
+  - /rust/reference/swim-libraries.html
+---
+
+Swim implements a complete, self-contained, distributed application stack in an embeddable software library. To develop server-side Swim apps, add the [swim-api](https://github.com/swimos/swim/tree/main/swim-java/swim-runtime/swim-host/swim.api) library to your Java project. To write a JavaScript client application, install the [@swim/client](https://www.npmjs.com/package/@swim/client) library from NPM. Select one of the boxes below (or scroll down) to get started with Swim.
+
+<!-- <div class="platform-case">
+  <svg viewBox="0 0 100 100" preserveAspectRatio="none" class="plane">
+    <path fill="#e8e8e8" d="M 0 100 L 10 0 L 90 0 L 100 100 Z"></path>
+  </svg>
+  <div class="server-server platform-horizontal-center"></div>
+  <div class="server-client platform-vertical-left"></div>
+  <div class="server-client platform-vertical-right"></div>
+  <div class="client-ui platform-vertical-right"></div>
+  <a class="plane-label">Plane</a>
+  <a href="#java-server" class="java-server platform-box platform-left">Java Server</a>
+  <a href="#java-client" class="java-client platform-box platform-left">Java Client</a>
+  <a href="#java-server" class="java-server platform-box platform-right">Java Server</a>
+  <a href="#js-client" class="js-client platform-box platform-right">JavaScript Client</a>
+  <a href="#web-ui" class="web-ui platform-box platform-right">Web UI</a>
+</div>
+<div class="release-stack">
+  <p class="release-version">Current version: 4.1.0.12</p>
+  <!-- <p class="release-notes"><a href="">View Release Notes</a></p>-->
+<!-- </div> -->
+
+To try Swim, check out one of our step-by-step [tutorials]({% link _rust_tutorials/index.md %}). To build your own app, try cloning a [starter application](https://github.com/swimos/tutorial). Or continue reading to learn more about how to get started with Swim.
+
+### Java Server Quick Start
+
+The Swim Java Server is a self-contained, distributed application server for stateful, streaming applications. Swim Server provides applications with persistence without a database, point-to-point messaging without a message broker, and execution scheduling without a job manager. Swim applications communicate using the WARP protocol, a multiplexed streaming upgrade to HTTP.
+
+```java
+group: "org.swimos",
+name: "swim-server",
+version: "4.2.14"
+```
+
+### Java Client Quick Start
+
+The Swim Java Client is a minimal WARP streaming API client.
+
+```java
+group: "org.swimos",
+name: "swim-client",
+version: "4.2.14"
+```
+
+### JavaScript Client Quick Start
+
+The Swim JavaScript Client is a WARP streaming API client for Node.js and browser applications.
+
+```console
+npm i @swim/client@dev
+```
+
+Visit the [**frontend documentation**](/frontend) for more on how to write a JavaScript client application.
+
+### Next Steps
+
+Continue reading to tryout step-by-step lessons with Swim. Or dive into the core Swim [concepts]({% link _rust_backend/index.md %}).
diff --git a/src/_rust_backend/time-series.md b/src/_rust_backend/time-series.md
new file mode 100644
index 0000000..9ef0a08
--- /dev/null
+++ b/src/_rust_backend/time-series.md
@@ -0,0 +1,263 @@
+---
+title: Time Series Data
+short-title: Time Series Data
+description: "How to represent and maintain time series data"
+group: Swim Apps
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/time_series
+redirect_from:
+  - /rust/guides/time-series.html
+---
+
+A common form of data is time series data - that is data indexed by time (timestamped).
+
+## Representation
+
+Time series data is a perfect candidate for a Swim [`MapLane`]({% link _rust_backend/map-lanes.md %}).
+Using `Long` as the key type, you can create a streaming map indexed by timestamp:
+
+```java
+@SwimLane("history")
+public MapLane<Long, Value> history = this.<Long, Value>mapLane();
+```
+
+This will create an empty map on agent instantiation with the name `history`.
+In this example the data is stored as Swim `Value`s, but this can be changed to any type
+(built-ins trivially, and custom types by using [`Forms`]({% link _rust_backend/forms.md %})).
+
+## Adding Data
+
+Adding to a Swim `MapLane` is almost identical to adding to an ordinary Java `Map`.
+Simply call the `put(K key, V value)` method to add the key-value data into the map:
+
+```java
+this.history.put(
+    System.currentTimeMillis(),
+    Record.create(2).slot("id", 1).slot("status", "enabled")
+);
+```
+
+This will insert a dummy value into the above `history` map lane with the current time as key.
+
+## Windowing
+
+We can now make use of a `MapLane`'s callback functions to maintain the map and implement some form of windowing or retention policy.
+
+### By Record Count
+
+We can implement a policy where the map will only store the **N** most recent records.
+
+First we create a method that when called will trim the map to the desired size.
+As `MapLane`s are ordered by key we can use the `drop(int count)` method to drop the oldest `count` records.
+
+Next we just call the method from the `history` lane's `didUpdate` callback, this will trim the map after a new record is added.
+
+```java
+  private final static int MAX_HISTORY_SIZE = 10;
+
+  @SwimLane("history")
+  public MapLane<Long, Value> history = this.<Long, Value>mapLane()
+    .didUpdate((k,n,o) -> trimHistory());
+
+  private void trimHistory() {
+    final int dropCount = this.history.size() - MAX_HISTORY_SIZE;
+    if (dropCount > 0) {
+      this.history.drop(dropCount);
+    }
+  }
+```
+
+This will create a `history` time series lane and maintains a record count of 10 (`MAX_HISTORY_SIZE`).
+
+See this in an agent in the [example](https://github.com/swimos/cookbook/blob/master/time_series/src/main/java/swim/timeseries/CountWindowAgent.java).
+
+### By Time
+
+We can implement a policy where the map will only store records within **N** amount of time of the most recent record.
+
+First we create a method that when called will trim the map of any old records.
+As `MapLane`s are ordered by key we can use the `lastKey()` method to obtain the most recent timestamp, subtracting our time interval we obtain a cut-off time for old records.
+
+Using the lane's `iterator()` we can iterate through the records, starting at the oldest (as iterators are ordered by key), removing any records that are older than the cut-off time.
+Once we reach a record more recent than the cut-off time, we can stop.
+
+Next we just call the method from the `history` lane's `didUpdate` callback, this will trim the map after a new record is added.
+
+```java
+  private static final long TIME_INTERVAL_MS = 30000L;
+
+  @SwimLane("history")
+  public MapLane<Long, Value> history = this.<Long, Value>mapLane()
+      .didUpdate((k,n,o) -> trimHistory());
+
+  private void trimHistory() {
+    final long oldestAllowedTimestamp = this.history.lastKey() - MAX_HISTORY_TIME_MS;
+    final Iterator<Long> iterator = this.history.keyIterator();
+
+    while (iterator.hasNext()) {
+      final long key = iterator.next();
+      if (key < oldestAllowedTimestamp) {
+        // If the key is too old then remove it
+        this.history.remove(key);
+      } else {
+        // Keys are ordered so stop when first key within the allowed time is found
+        break;
+      }
+    }
+  }
+```
+
+This will create a `history` time series lane and drop records that are not in a 30s (`TIME_INTERVAL_MS`) time interval of the most recent record.
+
+See this in an agent in the [example](https://github.com/swimos/cookbook/blob/master/time_series/src/main/java/swim/timeseries/TimeWindowAgent.java).
+
+### By Recency
+
+We can implement a policy where the map will only store records for **N** amount of time.
+
+First we create a method that when called will trim the map of any old records.
+Taking the current time and subtracting the maximum age of a record we want, we obtain a cut-off time for old records.
+
+Using the lane's `iterator()` we can iterate through the records, starting at the oldest (as iterators are ordered by key), removing any records that are older than the cut-off time.
+Once we reach a record more recent than the cut-off time, we can stop.
+
+```java
+  private void trimHistory() {
+    final long oldestAllowedTimestamp = System.currentTimeMillis() - MAX_HISTORY_TIME_MS;
+    final Iterator<Long> iterator = this.history.keyIterator();
+
+    while (iterator.hasNext()) {
+      final long key = iterator.next();
+      if (key < oldestAllowedTimestamp) {
+        // If the key is too old then remove it
+        this.history.remove(key);
+      } else {
+        // Keys are ordered so stop when first key within the allowed time is found
+        break;
+      }
+    }
+  }
+```
+
+_Note: Unlike the previous section, it is not sufficient to just call this method whenever a new record is added - we still want to continue checking for old records, even if no new records are added._
+
+Next we are going to create and manage a [`Timer`]({% link _rust_backend/timers.md %}) that will handle the calling of the `trimHistory()` method we just created.
+Ideally we want to manage one timer and that timer needs to trigger as soon as a record needs to be removed.
+
+Calculating the time until the next record needs to be dropped can be done by taking the oldest record time (calling `firstKey()` on the lane) adding maximum age of a record, then subtracting the current time.
+
+Using this calculated time we can now make use of the web agent's `setTimer(long millis, TimerFunction timer)` method to handle the scheduling of `trimHistory()`.
+
+```java
+  private static final long MAX_HISTORY_TIME_MS = 30000L;
+
+  private TimerRef timer;
+
+  private void rescheduleNextTrim() {
+    final long timeUntilNextTrim = (this.history.firstKey() + MAX_HISTORY_TIME_MS) - System.currentTimeMillis();
+    this.timer = setTimer(timeUntilNextTrim, this::trimHistory);
+
+  }
+```
+
+We call the `rescheduleNextTrim()` method we just created from the `history` lane's `didUpdate` callback, this will schedule a timer to trim the map whenever a new record is added.
+
+Finally, we need to account for a few things:
+
+- If two records are added in quick succession, `rescheduleNextTrim()` will be called twice, creating two timers.
+  To prevent this we add a check at the start of `rescheduleNextTrim()`, if there is already a timer scheduled, do nothing.
+- Currently, after the timer triggers `trimHistory()`, it is not called again until a new record is added.
+  What we would like to happen is for the timer to reschedule itself if the map is not empty after it is finished trimming.
+  Adding a call to `rescheduleNextTrim()` before the `break` in our loop will have this affect.
+- It is possible to obtain a negative number when calculating the delay for the timer - meaning the oldest record should be removed immediately.
+  We simply check for this and call `trimHistory()` if the number calculated is less than zero.
+
+```java
+  private static final long MAX_HISTORY_TIME_MS = 30000L;
+
+  private TimerRef timer;
+
+  @SwimLane("history")
+  public MapLane<Long, Value> history = this.<Long, Value>mapLane()
+    .didUpdate((k,n,o) -> rescheduleNextTrim());
+
+  private void trimHistory() {
+    final long oldestAllowedTimestamp = System.currentTimeMillis() - MAX_HISTORY_TIME_MS;
+    final Iterator<Long> iterator = this.history.keyIterator();
+
+    while (iterator.hasNext()) {
+      final long key = iterator.next();
+      if (key < oldestAllowedTimestamp) {
+        // If the key is too old then remove it
+        this.history.remove(key);
+      } else {
+        // Keys are ordered so stop when first key within allowed time is found
+        rescheduleNextTrim();
+        break;
+      }
+    }
+  }
+
+  private void rescheduleNextTrim() {
+    if (this.timer != null && this.timer.isScheduled()) {
+      // The timer is already being handled
+      return;
+    }
+
+    final long timeUntilNextTrim = (this.history.firstKey() + MAX_HISTORY_TIME_MS) - System.currentTimeMillis();
+    if (timeUntilNextTrim > 0) {
+      // Set a timer for when the next record needs to be dropped
+      this.timer = setTimer(timeUntilNextTrim, this::trimHistory);
+    } else if (!this.history.isEmpty()) {
+      // A record needs to be dropped now
+      trimHistory();
+    }
+  }
+```
+
+This will create a `history` time series lane and drop records after 30 seconds (`MAX_HISTORY_TIME_MS`).
+
+See this in an agent in the [example](https://github.com/swimos/cookbook/blob/master/time_series/src/main/java/swim/timeseries/RecencyWindowAgent.java).
+
+## Simultaneous Events
+
+There's a catch to representing timeseries as timestamp-keyed `Maps`.
+Because any `Map` key can appear at most once, processing multiple events with the same timestamp retains only the last-processed event.
+
+### Compound Keys
+
+If the aforementioned behavior is undesirable, we recommend instead using `Value`-typed _compound keys_ that wrap both a timestamp and some (unique) event identifier.
+Two examples include:
+
+```java
+key = Record.create(2).slot("timestamp", timestamp).slot("id", id);
+```
+
+and
+
+```java
+key = Record.create(2).item(timestamp).item(id);
+```
+
+`MapLanes` are always ordered by key, and `Value`s are compared sequentially in field order (similarly to how _composite keys_ work in SQL).
+Thus, the **Windowing** section remains relevant to compound-keyed `MapLane`s; just be sure to correctly extract timestamps from keys first.
+For the above examples, this would look like
+
+```java
+key.get("timestamp").longValue();
+```
+
+and
+
+```java
+key.getItem(0).longValue();
+```
+
+respectively.
+
+### Chained Values
+
+Using compound keys precludes using `MapLane.get(timestamp)` to quickly seek entries under a provided timestamp.
+If your application requires this _uncommon_ functionality, and _only if_ iterating over the compound-keyed `MapLane` proves too inefficient, implement the timeseries as a `MapLane<Long, List<Value>>` (or similar) instead.
+
+_Note: this representation makes it trickier to both iterate over and join to the `MapLane`._
diff --git a/src/_rust_backend/timers.md b/src/_rust_backend/timers.md
new file mode 100644
index 0000000..9f587f3
--- /dev/null
+++ b/src/_rust_backend/timers.md
@@ -0,0 +1,138 @@
+---
+title: Timers
+short-title: Timers
+description: "Schedule tasks for future execution in Web Agents."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/timers
+redirect_from:
+  - /rust/tutorials/timers/
+  - /rust/reference/timers.html
+---
+
+The ability for a Swim server to repeatedly trigger custom actions at Agent-level whim is often a desired feature in a Swim application. Swim provides the means to set timers, which enable users to both define functions (called TimerFunctions) and trigger them at desired times.
+
+### Internals
+
+Swim uses a hashed timing wheel, implemented in swim.concurrent.Clock, to schedule its timers. For a clock with r-millisecond resolution and b buckets that each store a simple queue, non-decreasing by target tick:
+
+- Timer scheduling involves computing a trivial (modulo) hash to identify the desired bucket, then inserting in the right position in a queue.
+- Timer cancellation involves removing the timer from its queue without evaluating its TimerFunction.
+- A "tick" involves waiting for r milliseconds, then examining the next bucket.
+- When the scheduler reaches a bucket, every timer in it whose expiry time aligns with the current tick is submitted for execution.
+
+b and r are configurable by the system properties swim.clock.tick.count and swim.clock.tick.millis and default to 512 and 100, respectively.
+
+### Declaration
+
+A TimerRef is a concrete handle to the timer logic that a user wishes to execute. Such a handle can additionally be used to check the status of, reschedule, and cancel the corresponding timer. TimerRefs are simply declared as fields within Agents:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.agent.AbstractAgent;
+import swim.concurrent.TimerRef;
+
+public class UnitAgent extends AbstractAgent {
+  private TimerRef timer;
+}
+```
+
+### Instantiation
+
+Every AbstractAgent comes with a utility method, setTimer, to initialize a TimerRef. setTimer(long millis, TimerFunction f) schedules f for execution after an initial delay of milliseconds.
+
+Suppose we wanted to identify how long it has been, with one-minute resolution, since the last time an Agent received a command. One solution requires three pieces:
+
+- A value lane to store this duration
+- A command lane whose onCommand() callback sets the value lane to 0, then schedules a new timer
+- The aforementioned timer goes off every minute since it was issued, and its TimerFunction simply increments the value lane's value by 1.
+
+Every TimerRef has access to reschedule() and cancel() methods. Combining these with the aforementioned setTimer() call gives a user complete control over when (or not) to fire its events.
+
+Putting these pieces together looks something like the following; note that "minutes" here means 10 seconds, just to speed up an otherwise very slow demo:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.api.lane.ValueLane;
+import swim.concurrent.TimerRef;
+import swim.structure.Value;
+
+public class UnitAgent extends AbstractAgent {
+
+  private TimerRef timer;
+
+  @SwimLane("minutesSincePublish")
+  ValueLane<Integer> minutes = this.<Integer>valueLane()
+      .didSet((n, o) -> {
+        System.out.println((n * 10) + " seconds since last event");
+      });
+
+  @SwimLane("publish")
+  CommandLane<Value> publish = this.<Value>commandLane()
+      .onCommand(v -> {
+        this.minutes.set(0);
+        resetTimer();
+      });
+
+  @Override
+  public void didStart() {
+    resetTimer();
+  }
+
+  @Override
+  public void willStop() {
+    cancelTimer();
+  }
+
+  private void resetTimer() {
+    cancelTimer();
+    this.timer = setTimer(10000, () -> {
+        this.minutes.set(this.minutes.get() + 1);
+        this.timer.reschedule(10000);
+      });
+  }
+
+  private void cancelTimer() {
+    if (this.timer != null) {
+      this.timer.cancel();
+    }
+  }
+}
+```
+
+And here's a client that can exercise it:
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.client.ClientRuntime;
+import swim.structure.Value;
+
+class CustomClient {
+
+  public static void main(String[] args) throws InterruptedException {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+    final String hostUri = "warp://localhost:9001";
+    final String nodeUri = "/unit/foo";
+    for (int i = 0; i < 10; i++) {
+      swimClient.command(hostUri, nodeUri, "publish", Value.absent());
+      Thread.sleep(5000 * i);
+    }
+    System.out.println("Will shut down client");
+    swimClient.stop();
+  }
+}
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/timers).
diff --git a/src/_rust_backend/value-lanes.md b/src/_rust_backend/value-lanes.md
new file mode 100644
index 0000000..88f0295
--- /dev/null
+++ b/src/_rust_backend/value-lanes.md
@@ -0,0 +1,203 @@
+---
+title: Value Lanes
+short-title: Value Lanes
+description: "Define persistent properties of Web Agents, and continuously stream real-time state changes."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/value_lanes
+redirect_from:
+  - /rust/tutorials/value-lanes/
+  - /rust/reference/value-lanes.html
+---
+
+In the [Web Agents guide]({% link _rust_backend/web-agents.md %}), we describe a distributed object model where **Web Agents** are the **objects**. The **fields** in this model are called **lanes**.
+
+Lanes come in many flavors, but every lane type exposes:
+
+- A **means to act** on this lane
+- Customizable **lifecycle callbacks** that execute during the runtime of this action
+- Various means to **strongly type** (i.e. _parametrize_) the lane
+- Universal WARP **subscriptions** to this lane
+
+A **value lane** stores a **scalar** value and still meets these requirements:
+
+- Every value lane can be **set** with a value
+- Doing so will trigger its **didSet()** callback
+- The parameter on a value lane indicates the type of value that it stores
+- Value lane state and lifecycle can be subscribed to via both **value downlinks** and general-purpose **event downlinks**
+
+### Declaration
+
+All lanes are declared inside Web Agents as fields annotated with `@SwimLane`. The parameter inside this annotation is the lane's **laneUri**. Recall that every Web Agent has a universal, logical address known as its **nodeUri**; laneUris are simply the equivalent counterpart for lanes.
+The following declaration is sufficient to make the `info` lane of every `UnitAgent` addressable by the laneUri `"info"`:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.ValueLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("info")
+  ValueLane<String> info;
+}
+```
+
+Internally, lanes are always backed by `swim.structure.Value`s, regardless of their parametrized types. Under the hood, lanes use **forms** to handle any necessary conversions, allowing users to treat lanes as properly parametrized data types provided that a form for that data type exists. Even custom Java classes can be lane types, provided that forms for those classes exist. We will further discuss this topic in a more advanced cookbook.
+
+<!-- Further reading: <a href="/reference/universal-addressability">Universal Addressability</a>, <a href="/reference/structures">Structures</a>
+-->
+
+### Instantiation and `didSet()`
+
+The `AbstractAgent` class comes with utility methods to construct runnable lanes. Recall, however, that developers rarely instantiate Web Agents by explicitly invoking their constructors. The recommended pattern for adding a value lane to an Agent is instead to:
+
+- Exclude constructors entirely from Web Agents
+- Use the `valueLane()` method to instantiate the lane; note that this is a parametrized method
+- Through a builder pattern, override the lane's `void didSet(V newValue, V oldValue)` method
+
+This **didSet()** lifecycle callback is executed every time its lane is set to some value, and it has access to both the recently-updated value and its immediately prior one.
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.ValueLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("info")
+  ValueLane<String> info = this.<String>valueLane()
+      .didSet((newValue, oldValue) -> {
+        logMessage("`info` set to " + newValue + " from " + oldValue);
+      });
+
+  private void logMessage(Object msg) {
+    System.out.println(nodeUri() + ": " + msg);
+  }
+}
+```
+
+{% include alert.html title='Caution' text='If you have multiple lanes within an Agent type, ensure that their laneUris are not identical. Suppose we declare two different value lanes within our <strong>UnitAgent</strong> with laneUri <strong>"info"</strong>; how does the Swim runtime know which one to set? That said, reusing laneUris <strong>across</strong> Agent types is perfectly acceptable, as requests corresponding to these are guaranteed to have different nodeUris.' %}
+
+### External Addressability
+
+Lanes are Swim server endpoints; therefore, external processes must be able to access them directly. Just like to accessing the `foo` field of an object `obj` in object-oriented paradigms requires both `obj` and `foo` in some way (e.g. `obj.foo`), addressing a lane requires both its laneUri and the nodeUri of its enclosing agent. Additionally, if the request comes from a different Swim runtime from where the target lane lives (i.e. an entirely different plane or a Swim client instance), then the request must also identify the **hostUri** on which the Swim server is running.
+
+Unlike with `command()` for command lanes, there is no general-purpose Swim API **method** to talk to value lanes (it's still possible, but we'll get to that in a bit). However, all lanes **within** an agent can directly reference each other in their callback functions. So, one common way to write to a value lane is to create a separate command lane whose `onCommand()` callback acts as a proxy:
+
+```java
+// swim/basic/UnitAgent.java
+package swim.basic;
+
+import swim.api.SwimLane;
+import swim.api.agent.AbstractAgent;
+import swim.api.lane.CommandLane;
+import swim.api.lane.ValueLane;
+
+public class UnitAgent extends AbstractAgent {
+  @SwimLane("info")
+  ValueLane<String> info = this.<String>valueLane()
+      .didSet((newValue, oldValue) -> {
+        logMessage("'info' set to '" + newValue + "' from '" + oldValue + "'");
+      });
+
+  @SwimLane("publishInfo")
+  CommandLane<String> publishInfo = this.<String>commandLane()
+      .onCommand(msg -> {
+        this.info.set("from publishInfo: " + msg);
+      });
+
+  private void logMessage(Object msg) {
+    System.out.println(nodeUri() + ": " + msg);
+  }
+}
+```
+
+Direct communication with value lanes is instead accomplished through **downlinks**. Downlinks are WARP subscriptions to lanes. They come in many flavors, but subscriptions to value lanes can only be accomplished through **value downlinks** and, to a more limited extent, **event downlinks**.
+
+Further reading: [Command Lanes](/reference/command-lanes), [Downlinks](/reference/downlinks)
+
+### Writing to Value Lanes
+
+Value downlinks can be instantiated using the `downlinkValue()` method from any Swim handle, as long as the desired hostUri (optional if the target lane is within the same Swim handle), nodeUri, and laneUri are known in advance. Once a value downlink is initialized, `set()` can be directly invoked on it, as if it were the underlying lane itself.
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.api.downlink.ValueDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Text;
+import swim.structure.Value;
+
+class CustomClient {
+  public static void main(String[] args) throws InterruptedException {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+    final String hostUri = "warp://localhost:9001";
+    final String nodeUri = "/unit/master";
+    swimClient.command(hostUri, nodeUri, "WAKEUP", Value.absent());
+    // Send using either the proxy command lane...
+    swimClient.command(hostUri, nodeUri, "publishInfo", Text.from("Hello from command, world!"));
+    // ...or a downlink set()
+    final ValueDownlink<Value> link = swimClient.downlinkValue()
+        .hostUri(hostUri).nodeUri(nodeUri).laneUri("info")
+        .open();
+    link.set(Text.from("Hello from link, world!"));
+
+    System.out.println("Will shut down client in 2 seconds");
+    Thread.sleep(2000);
+    swimClient.stop();
+  }
+}
+```
+
+### Reading from Value Lanes
+
+There are two ways to read data from value lanes, both of which require opening a downlink.
+The simpler approach is to simply call `get()` on the downlink to read its value at the time of the invocation.
+The far more powerful approach uses the fact that value downlinks _also_ have access to `didSet()`. This enables an event-driven style of programming where client programs are treated as completely in sync with the server. And, excluding network latency and backpressure regulation of network packets, they basically are.
+
+```java
+// swim/basic/CustomClient.java
+package swim.basic;
+
+import swim.api.downlink.ValueDownlink;
+import swim.client.ClientRuntime;
+import swim.structure.Text;
+import swim.structure.Value;
+
+class CustomClient {
+  public static void main(String[] args) throws InterruptedException {
+    ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+    final String hostUri = "warp://localhost:9001";
+    final String nodeUri = "/unit/master";
+    swimClient.command(hostUri, nodeUri, "WAKEUP", Value.absent());
+    // Link with a didSet() override
+    final ValueDownlink<Value> link = swimClient.downlinkValue()
+        .hostUri(hostUri).nodeUri(nodeUri).laneUri("info")
+        .didSet((newValue, oldValue) -> {
+          System.out.println("link watched info change to " + newValue + " from " + oldValue);
+        })
+        .open();
+    // Send using either the proxy command lane...
+    swimClient.command(hostUri, nodeUri, "publishInfo", Text.from("Hello from command, world!"));
+    // ...or a downlink set()
+    link.set(Text.from("Hello from link, world!"));
+    System.out.println("synchronous link get: " + link.get());
+
+    System.out.println("Will shut down client in 2 seconds");
+    Thread.sleep(2000);
+    swimClient.stop();
+  }
+}
+```
+
+### Try It Yourself
+
+A standalone project that combines all of these snippets and handles any remaining boilerplate is available [here](https://github.com/swimos/cookbook/tree/master/value_lanes).
diff --git a/src/_rust_backend/value.md b/src/_rust_backend/value.md
new file mode 100644
index 0000000..e69de29
diff --git a/src/_rust_backend/web-agents.md b/src/_rust_backend/web-agents.md
new file mode 100644
index 0000000..756883f
--- /dev/null
+++ b/src/_rust_backend/web-agents.md
@@ -0,0 +1,144 @@
+---
+title: Web Agents
+short-title: Web Agents
+description: "Learn about declaring, defining and utilizing Web Agents and their properties using configuration files."
+group: Reference
+layout: documentation
+cookbook: https://github.com/swimos/cookbook/tree/master/web_agents
+redirect_from:
+  - /rust/tutorials/web-agents/
+  - /rust/reference/web-agents.html
+---
+
+Swim servers utilize a general purpose distributed object model in which the objects are called **Web Agents**.
+Programming with this model feels like typical object-oriented programming with additional key innovations in addressability, statefulness, consistency, boundedness, and composability.
+
+Although this analogy holds very well for the most part, there are two important catches:
+
+- Methods, while still being able to define arbitrarily complicated logic, are not directly invoked. Instead, Web agents come with **lifecycle callback** functions that are called during specified stages of a Web Agent's lifetime
+- Web Agent **instantiation** is not accomplished by invoking a constructor (at least from the programmer's perspective)
+
+Don't worry if these points feel restrictive through this article; much finer control becomes available once we discuss **lanes**.
+
+### Declaration
+
+Just like with (instantiable) `struct` declarations in Rust, **Agent declarations** in Swim define the behavior for **instances** of those Agents.
+Declarations alone don't actually instantiate anything.
+
+To declare a Web Agent, both agent and lifecycle structs must be declared:
+
+```rust
+use swim_os::agent::{projections, AgentLaneModel, lifecycle};
+
+#[derive(AgentLaneModel)]
+#[projections]
+pub struct ExampleAgent {
+    lane: ValueLane<i32>,
+}
+
+#[derive(Clone)]
+pub struct ExampleLifecycle;
+
+#[lifecycle(ExampleAgent)]
+impl ExampleLifecycle;
+```
+
+`#[derive(AgentLaneModel)]` derives the necessary traits for the agent; its schema and a constructor. To interact with lanes and their state, operations are performed through lifecycle handlers which provide access to a `HandlerContext` which requires a projection to the lane that you wish to perform some action against; this is covered in more detail in the [lanes]({% link _rust_backend/lanes.md %}) page. The `#[projections]` macro generates these projections for you which in the above example generates:
+
+```rust
+impl ExampleAgent {
+    pub LANE: fn(&ExampleAgent) -> &ValueLane<i32>
+}
+```
+
+If the lifecycle contains no fields, then the `#[lifecycle(ExampleAgent)]` macro is used to automatically generate the specified agent's lifecycle. Agents must **only** contain lanes and no other state. If this is required, it must be placed within the lifecycle of the agent and its constructor must be manually provided - which is covered later in this guide.
+
+### Addressability
+
+A Web Agent is only instantiated when it's `nodeUri` is invoked for the first time through addressing one of the lanes contained within the agent; though, an incorrectly addressed lane will still cause the agent to be instantiated.
+
+Node addresses come in two flavours:
+
+- Static: such as `"/sensors"`. If a static path is used, only one agent will ever exist at that address.
+- Dynamic: such as `"/sensor/:id`. For each unique address, a new agent will be instantiated. It is possible to get the route parameters (in our example, `"id`) that the agent was started with through the `HandlerContext` which is provided to agent lifecycle functions.
+
+When designing your Web Agents, carefully consider how you will be producing and consuming your data. If you were designing a system that contained a large number of sensors, it may make more sense to have sensor be its own Web Agent that is addressed through a dynamic address of `"/sensor/:id"` rather than rolling them all up into a static path. This would allow for a subscriber to receive only the specific state updates that they require rather than subscribing to the state changes of every sensor.
+
+### Agent Lifecycle Callbacks
+
+There are two lifecycle callbacks associated with a Web Agent:
+
+`on_start`: executed once immediately after this Agent has started:
+
+```rust
+use swim_os::agent::agent_lifecycle::utility::HandlerContext;
+
+impl ExampleAgent {
+    #[on_start]
+    pub fn on_start(
+        &self,
+        context: HandlerContext<ExampleAgent>,
+    ) -> impl EventHandler<ExampleAgent> {
+        context.get_agent_uri().and_then(move |uri| {
+            context.effect(move || {
+                println!("Starting agent at: {}", uri);
+            })
+        })
+    }
+}
+```
+
+`on_stop`: executed once immediately before this Agent will stop:
+
+```rust
+use swim_os::agent::agent_lifecycle::utility::HandlerContext;
+
+impl ExampleAgent {
+    #[on_start]
+    pub fn on_stop(
+        &self,
+        context: HandlerContext<ExampleAgent>,
+    ) -> impl EventHandler<ExampleAgent> {
+        context.get_agent_uri().and_then(move |uri| {
+            context.effect(move || {
+                println!("Stopping at: {}", uri);
+            })
+        })
+    }
+}
+```
+
+A Web Agent may stop if it has not received a message after a configurable period of time has elapsed; this is configurable through (todo rust doc link). If an agent has stopped and it receives a message, then the agent will restart and the `on_start` method will be invoked.
+
+### Persistence
+
+When enabled, messages propagated by a lane are guaranteed to have been persisted to the configured store. By default, all lanes within a Web Agent will have their state persisted to the store. If this is not desired, it is possible to disable persistence for a lane by applying the `#[lane(transient)]` attribute to a lane or apply disable persistence at the agent level by using `#[agent(transient)]`
+
+For a single lane:
+
+```rust
+use swim_os::{agent::lanes::MapLane, AgentLaneModel};
+
+#[derive(AgentLaneModel)]
+pub struct ExampleAgent {
+    #[lane(transient)]
+    temporary: MapLane<String, i32>
+}
+```
+
+To disable persistence for every lane you could apply the `#[lane(transient)]` attribute to every lane or use:
+
+```rust
+use swim_os::{agent::{lanes::MapLane, ValueLane}, AgentLaneModel};
+
+#[derive(AgentLaneModel)]
+#[agent(transient)]
+pub struct ExampleAgent {
+    count: ValueLane<i32>,
+    names: MapLane<String, String>
+}
+```
+
+When an agent first starts, it will attempt to load the state of all the lanes from the configured store. Any lanes marked as `transient` will not have any state reloaded.
+
+For more details on Web Agent persistence see the [persistence]({% link _rust_backend/persistence.md %}) page.
diff --git a/src/_rust_devguide/1-introduction.md b/src/_rust_devguide/1-introduction.md
new file mode 100644
index 0000000..80bebfa
--- /dev/null
+++ b/src/_rust_devguide/1-introduction.md
@@ -0,0 +1,22 @@
+---
+title: 1. Introduction
+short-title: Introduction
+description: "Introduction to the SwimOS developer guide."
+group: Introduction
+layout: documentation
+redirect_from:
+  - /rust/developer-guide/introduction
+  - /rust/developer-guide/introduction.html
+---
+
+Welcome to the SwimOS developer's guide, an introductory guide to the SwimOS framework.
+With SwimOS, you can dive into building applications without getting bogged down by intricate infrastructure details – it takes care of the 'plumbing' so you can concentrate on crafting robust application logic.
+
+In this guide, we'll explore the fundamental concepts and practical aspects of SwimOS, focusing on its features.
+Our goal is to equip you with the knowledge and skills to harness the full potential of SwimOS for developing real-time applications.
+While we'll cover the 'how' of building streaming apps, if you're interested in understanding the 'why' behind it, you may find our reference documentation more insightful.
+
+# Who This Guide Is For
+
+This guide assumes that you've written code in Rust before, as such we will not explain any Rust specific features or syntax.
+We will focus on features of the SwimOS framework which by design aren't overly complex to use, although some background knowledge of software development technologies is required.
diff --git a/src/_rust_devguide/2-getting-started.md b/src/_rust_devguide/2-getting-started.md
new file mode 100644
index 0000000..6e5e07d
--- /dev/null
+++ b/src/_rust_devguide/2-getting-started.md
@@ -0,0 +1,13 @@
+---
+title: 2. Getting Started
+short-title: Getting Started
+description: "Getting Started using SwimOS."
+group: Getting Started
+layout: documentation
+redirect_from:
+  - /rust/developer-guide/getting-started
+  - /rust/developer-guide/getting-started.html
+---
+
+Let's get started on the SwimOS journey.
+In this chapter we will discuss project setup and create the most basic SwimOS 'Hello, world!' server and extend it to incorporate some SwimOS core concepts, agents and lanes.
diff --git a/src/_rust_devguide/2.1-project-setup.md b/src/_rust_devguide/2.1-project-setup.md
new file mode 100644
index 0000000..d9a7be9
--- /dev/null
+++ b/src/_rust_devguide/2.1-project-setup.md
@@ -0,0 +1,66 @@
+---
+title: 2.2. Manual Project Setup
+short-title: Project Setup
+description: "Set up a blank SwimOS project."
+group: Getting Started
+layout: documentation
+redirect_from:
+  - /rust/developer-guide/project-setup
+  - /rust/developer-guide/project-setup.html
+---
+
+To initiate the setup of a SwimOS project, start by creating and navigating to the directory where it will be located. First, lets start by creating a new server project named `server`:
+
+```shell
+cargo new server --bin
+```
+
+Then we need to declare our dependencies. Let's start by adding the following to our `Cargo.toml`:
+
+```toml
+[dependencies]
+swimos = "{{ site.data.rust-crates.swimos-version }}"
+swimos_client = "{{ site.data.rust-crates.swimos-client-version }}"
+tokio = { "{{ site.data.rust-crates.tokio-version }}", features = ["full"] }
+```
+
+The SwimOS platform is built using the `tokio` runtime so we need to include it.
+
+Lets add the required imports for our example application to the `main.rs` file:
+
+```rust
+use swim::{
+    agent::{
+        agent_lifecycle::utility::HandlerContext,
+        agent_model::AgentModel,
+        event_handler::{EventHandler, HandlerActionExt},
+        lanes::ValueLane,
+        lifecycle, projections, AgentLaneModel,
+    },
+    route::RoutePattern,
+    server::{Server, ServerBuilder, ServerHandle},
+};
+```
+
+Now lets add our client project named `client`:
+
+```shell
+cargo new client --bin
+```
+
+Then we need to declare our dependencies in our `Cargo.toml` file:
+
+```toml
+[dependencies]
+swimos_client = "{{ site.data.rust-crates.swimos-client-version }}"
+tokio = { "{{ site.data.rust-crates.tokio-version }}", features = ["full"] }
+```
+
+Lets add the required imports for our example application to the `main.rs` file:
+
+```rust
+use client::{BasicValueDownlinkLifecycle, DownlinkConfig, RemotePath, SwimClientBuilder};
+use std::str::FromStr;
+```
+
+The Minimum Supported Rust Version is 1.76.0.
diff --git a/src/_rust_devguide/2.2-hello-agent.md b/src/_rust_devguide/2.2-hello-agent.md
new file mode 100644
index 0000000..cfdaddd
--- /dev/null
+++ b/src/_rust_devguide/2.2-hello-agent.md
@@ -0,0 +1,278 @@
+---
+title: 2.2. Hello, Agent!
+short-title: Hello, Agent!
+description: "Instantiate some SwimOS Web Agents."
+group: Getting Started
+layout: documentation
+redirect_from:
+  - /rust/developer-guide/hello-agent
+  - /rust/developer-guide/hello-agent.html
+---
+
+Having completed the setup, we're ready to continue our tutorial application. We'll now incorporate SwimOS's fundamental building blocks - agents.
+
+# Agents
+
+A Stateful Object is a simple structural representation of an entity that lives amongst your streaming data. A Stateful Object continuously consumes updates of synced state and for each update, it computes new state that automatically gets synced to listeners. In SwimOS, these Stateful Objects are named Agents and the state contained within them is exposed through Lanes; these are similar to `Durable State` in Akka and `State` in Flink but the state is addressable using a URI relative to an instance of an Agent.
+
+Agents are defined using structs that can be automatically derived using the declared macros below. Lets define one in our `server/src/main.rs` file:
+
+```rust
+#[derive(AgentLaneModel)]
+#[projections]
+pub struct ExampleAgent {
+    state: ValueLane<i64>,
+}
+
+/// A lifecycle must be associated with an agent so that it can react to any events
+/// that happen during its lifetime.
+#[derive(Clone)]
+pub struct ExampleLifecycle;
+
+/// Here we bind this struct's implementation to our agent above.
+#[lifecycle(ExampleAgent)]
+impl ExampleLifecycle {
+    /// This method will be invoked when the agent starts.
+    #[on_start]
+    pub fn on_start(
+        &self,
+        context: HandlerContext<ExampleAgent>,
+    ) -> impl EventHandler<ExampleAgent> {
+        context.get_agent_uri().and_then(move |uri| {
+            context.effect(move || {
+                println!("Starting agent at: {}", uri);
+            })
+        })
+    }
+
+    /// This method will be invoked when the agent stops.
+    #[on_stop]
+    pub fn on_stop(
+        &self,
+        context: HandlerContext<ExampleAgent>,
+    ) -> impl EventHandler<ExampleAgent> {
+        context.get_agent_uri().and_then(move |uri| {
+            context.effect(move || {
+                println!("Stopping agent at: {}", uri);
+            })
+        })
+    }
+
+    /// This method will be invoked when the `ValueLane` named `"lane"` receives
+    /// an update.
+    #[on_event(lane)]
+    pub fn on_event(
+        &self,
+        context: HandlerContext<ExampleAgent>,
+        value: &i64,
+    ) -> impl EventHandler<ExampleAgent> {
+        let n = *value;
+        context.effect(move || {
+            println!("Setting value to: {}", n);
+        })
+    }
+}
+
+
+```
+
+{% capture alert_text %}
+Any type parameters used by a Lane must implement the <a href="https://doc.rust-lang.org/std/marker/trait.Send.html" style="color: lightblue; font-weight: bold;">Send</a> and <a href="{% link _rust_backend/forms.md %}" style="color: lightblue; font-weight: bold;">Form</a> traits.
+{% endcapture %}
+
+{% include alert.html title='Note' text=alert_text %}
+
+In our example above, we have added a single `ValueLane` to our agent that stores a single `i64` instance that is addressable through a lane URI of `"lane"`
+
+# Starting the server
+
+To build and run a server, we first need to map the schema of agents to a `ServerBuilder` and configure any properties.
+
+To register agents with a `ServerBuilder`, we need to associate the URIs of the agents with the agents. We do this as follows in `server/src/main.rs`:
+
+```rust
+#[tokio::main]
+async fn main() -> Result<(), Box<dyn Error + Send + Sync>> {
+    // Here we create a dynamic route named "/example/:name" to use for our `ExampleAgent`.
+    let route = RoutePattern::parse_str("/example/:name}")?;
+    let lifecycle = ExampleLifecycle;
+    // We can think of this as creating our agent factory that will be used to create
+    // instances of our agent.
+    let agent = AgentModel::new(ExampleAgent::default, lifecycle.into_lifecycle());
+
+    let server = ServerBuilder::with_plane_name("Plane")
+        .update_config(|config| {
+            // Ensure the agent stops fairly quickly.
+            config.agent_runtime.inactive_timeout = Duration::from_secs(20);
+        })
+        // Register the agent againt the route. Now, we can send events to `"/example/:name"`
+        // and a new agent will be started for every unique path that is addressed.
+        .add_route(route, agent)
+        .build()
+        // An error may be returned from this future if there is a connection issue or
+        // a path collision.
+        .await?;
+
+    // We've now got a future for the server and a handle that may be used to stop
+    // the server or receive the address that the listener has bound to.
+    let (task, handle) = server.run();
+    let shutdown = manage_handle(handle);
+
+    let (_, result) = tokio::join!(shutdown, task);
+
+    result?;
+    println!("Server stopped successfully.");
+    Ok(())
+}
+
+// Utility function for awaiting the listener's socket address and listening for a
+// stop signal in the terminal.
+async fn manage_handle(mut handle: ServerHandle) {
+    if let Some(addr) = handle.bound_addr().await {
+        println!("Bound to: {}", addr);
+        tokio::signal::ctrl_c()
+            .await
+            .expect("Failed to register interrupt handler.");
+    }
+
+    println!("Stopping server.");
+    handle.stop();
+}
+```
+
+# Interacting with the server
+
+To interact with our server, we need to use the `swimos_client` crate and connect to the lane that we wish to interact with using a Downlink. Downlinks provide the ability to execute state retreival and update operations against lanes on a server.
+
+We can downlink to a lane as follows in our `client/src/main.rs`:
+
+```rust
+#[tokio::main]
+async fn main() {
+    // Build a Swim Client using the default configuration.
+    // The `build` method returns a `SwimClient` instance and its internal
+    // runtime future that is spawned below.
+    let (client, task) = SwimClientBuilder::default().build().await;
+    let _client_task = tokio::spawn(task);
+    let handle = client.handle();
+
+    // We pass in the port that the server bound to and access it from the
+    // command line arguments provided.
+    let args = std::env::args().collect::<Vec<_>>();
+    let port = match args.get(1) {
+        Some(port) => usize::from_str(port.as_ref()).unwrap(),
+        None => panic!("No argument provided"),
+    };
+
+    // Build a path the downlink.
+    let state_path = RemotePath::new(
+        format!("ws://0.0.0.0:{}", port),
+        // We can provide any agent URI that matches the pattern
+        // "/example/:id"
+        "/example/1",
+        // This is the URI of the ValueLane<i32> in our ExampleAgent
+        "state",
+    );
+
+    let lifecycle = BasicValueDownlinkLifecycle::<usize>::default()
+        // Register an event handler that is invoked when the downlink connects to the  agent.
+        .on_linked_blocking(|| println!("Downlink linked"))
+        // Register an event handler that is invoked when the downlink synchronises its state
+        // with the agent.
+        .on_synced_blocking(|value| println!("Downlink synced with: {value:?}"))
+        // Register an event handler that is invoked when the downlink receives an event.
+        .on_event_blocking(|value| println!("Downlink event: {value:?}"));
+
+    // Build our downlink.
+    //
+    // This operation may fail due to a connection issue.
+    let state_downlink = handle
+        .value_downlink::<i64>(state_path)
+        .lifecycle(lifecycle)
+        .downlink_config(DownlinkConfig::default())
+        .open()
+        .await
+        .expect("Failed to open downlink");
+
+    for i in 0..10 {
+        // Update the agent's state.
+        state_downlink.set(i).await.expect("Failed to set downlink state");
+    }
+
+    tokio::signal::ctrl_c()
+        .await
+        .expect("Failed to listen for ctrl-c.");
+}
+```
+
+# Running
+
+We're now ready to run our server and client applications. First, we need to start the server.
+
+In the `server` directory run:
+
+```shell
+cargo run
+```
+
+Once the server has started and is listening for events you will see in the console the port that the server bound to:
+
+```
+Bound to: 0.0.0.0:56693
+```
+
+Copy the port that the server bound to (in the above example, 56693) and in the `client` directory execute the command below and paste the port.
+
+```shell
+cargo run -- 56693
+```
+
+## Client output
+
+In our client terminal, we'll see the below output:
+
+```
+Downlink linked
+Downlink synced with: 0
+Downlink event: 0
+Downlink event: 1
+Downlink event: 2
+Downlink event: 3
+Downlink event: 4
+Downlink event: 5
+Downlink event: 6
+Downlink event: 7
+Downlink event: 8
+Downlink event: 9
+```
+
+Lets have a look at the order of these events. The execution flow is `linked -> synced -> events`.
+
+When a downlink first connects to a lane, it sends a request to register for events (known as a link request) and it receives back a `linked` response envelope. The same happens for a sync request but before we receive a `synced` response, any state from the lane is transmitted to the client. Once our downlink has synced, we then receive any events from the lane; which in our example, we trigger. It's important to note, that state is transmitted to **all** linked registrants, which in this instance, includes our client's downlink.
+
+It's also possible to register a lifecycle event which is triggered when the downlink unlinks. This may be useful if you need to fire a subsequent event for when the agent stops (perhaps due to a timeout) or the server stops. It is also possible to create lifecycle event handlers that execute asynchronously or share state which is provided to the closure as an argument.
+
+## Server output
+
+After our configured timeout of 20 seconds, we'll see the below output in our server terminal:
+
+```
+Starting agent at: /example/1
+Setting value to: 0
+Setting value to: 1
+Setting value to: 2
+Setting value to: 3
+Setting value to: 4
+Setting value to: 5
+Setting value to: 6
+Setting value to: 7
+Setting value to: 8
+Setting value to: 9
+Stopping agent at: /example/1
+```
+
+Above, we can see that our `on_start` lifecycle event handler was invoked before any event handlers were invoked. Once no events have been received for our defined period of 20 seconds the agent will shutdown and propagate an `unlinked` envelope to all `linked` peers. A variety of event handlers may be defined for lanes which may be used to build up a workflow that reacts to incoming messages, potentially updates an agent's state, and propagates state to linked peers.
+
+# Full code
+
+The full code for this page is available at: [todo-link](todo-link).
diff --git a/src/_rust_devguide/2.3-forms.md b/src/_rust_devguide/2.3-forms.md
new file mode 100644
index 0000000..42a0a14
--- /dev/null
+++ b/src/_rust_devguide/2.3-forms.md
@@ -0,0 +1,14 @@
+---
+title: 2.3. Forms
+short-title: Forms
+description: "Custom structural types"
+group: Getting Started
+layout: documentation
+redirect_from:
+  - /rust/developer-guide/forms
+  - /rust/developer-guide/forms.html
+---
+
+SwimOS uses a lightweight encoding and decoding system for transcoding types between a SwimOS [Value]({% link _rust_backend/value.md %}) instance for communication between agents and a lane's type. Any type parameters used by a Lane must implement the [Form]({% link _rust_backend/forms.md %}) trait which defines how a type is transcoded; `Form` is a supertrait formed of `StructuralReadable` (for decoding) and `StructuralWritable` (for encoding).
+
+The aforementioned traits are implemented for most of the standard library that Serde's `Serialize` and `Deserialize` traits are implemented for and for most types simply annotating a struct or enum with `#[derive(Form)]` will suffice but for more complex types implementations may have to be manually defined. See [Form]({% link _rust_backend/forms.md %}) for more information.
diff --git a/src/_rust_devguide/2.4-lane-composition.md b/src/_rust_devguide/2.4-lane-composition.md
new file mode 100644
index 0000000..b9c0d00
--- /dev/null
+++ b/src/_rust_devguide/2.4-lane-composition.md
@@ -0,0 +1,141 @@
+---
+title: 2.4. Lane Composition
+short-title: Lane Composition
+description: "Lane Composition"
+group: Getting Started
+layout: documentation
+redirect_from:
+  - /rust/developer-guide/multiple-lanes
+  - /rust/developer-guide/multiple-lanes.html
+---
+
+In this section of the guide, we'll develop an agent that exposes functionality to add or subtract from a stored numerical state. To do this we'll introduct a new `CommandLane` type and expand on two previously mentioned topics: `ValueLane`s and `Form`s.
+
+For this section, simply copy the previous project to a new directory and then we can tweak it.
+
+Add these two `use` declarations in our server crate:
+
+```rust
+use swim::{lane::CommandLane, form::Form};
+```
+
+And for our client crate:
+
+```rust
+use swimos_client::Form;
+```
+
+# Command Lanes
+
+Command lanes are stateless lanes that provide a single event handler that may be registered, which, when invoked with the request payload (the _command_), returns an effect which may trigger updates to other lanes, update a database or any other functionality required.
+
+The _command_ type can be any type that implements the [Form]({% link _rust_backend/forms.md %}) trait; including enumerations which enable the lane to react to many different types of commands and for this section, will be either an `Add` or `Sub` variant.
+
+# Building the Agent
+
+Before diving in to building the agent, lets consider the design. We have the following requirements:
+
+- We need somewhere to store the state. We can use a `ValueLane<i64>` that's addressable using a URI of `"state"`
+- We will need to be able to react to `Add(i64)` and `Sub(i64)` requests. There's two approaches that we could take to this:
+  - Two separate `CommandLane<i64>`s; one addressable at a URI of `"add"` and the other at `"sub"`.
+  - One command lane `CommandLane<Operation>` that is addressable at `"exec"`. Where `Operation` is an enumeration with two variants: `Add(i64)` and `Sub(i64)`.
+
+The latter option is more sensible as it is simpler and all envelopes to agents are processed sequentially so there is no benefit to splitting this out. We can use the previously mentioned event handler and register one in the lifecyle of our agent and then match on the operation and update the state of the agent.
+
+Before we can start modelling our agent, we'll need to define our `Operation` type and derive the necessary traits:
+
+```rust
+// Note how as this is a custom type we need to derive `Form` for it.
+#[derive(Debug, Form, Copy, Clone)]
+pub enum Operation {
+    Add(i64),
+    Sub(i64),
+}
+```
+
+We can now define our agent as follows:
+
+```rust
+#[derive(AgentLaneModel)]
+#[projections]
+pub struct ExampleAgent {
+    state: ValueLane<i64>,
+    exec: CommandLane<Operation>,
+}
+```
+
+The `#[projections]` macro derives an accessor for retreiving a lane by it's name, which is used when working with event handlers. For our above agent, it looks as follows:
+
+```rust
+impl ExampleAgent {
+    pub const STATE: for<'a> fn(&'a Self) -> &'a ValueLane<i64> = |agent| &agent.state;
+    pub const EXEC: for<'a> fn(&'a Self) -> &'a CommandLane<Operation> = |agent| &agent.exec;
+}
+```
+
+We can now add our `on_command` event handler:
+
+```rust
+#[on_command(exec)]
+pub fn on_command(
+    &self,
+    context: HandlerContext<ExampleAgent>,
+    // Notice how we get a reference to the command envelope.
+    operation: &Operation,
+) -> impl EventHandler<ExampleAgent> {
+    let operation = *operation;
+    context
+        // Get the current state of our `state` lane.
+        .get_value(ExampleAgent::STATE)
+        .and_then(move |state| {
+            // Calculate the new state.
+            let new_state = match operation {
+                Operation::Add(val) => state + val,
+                Operation::Sub(val) => state - val,
+            };
+            // Return an effect which updates the state of the `state` lane.
+            context.set_value(ExampleAgent::STATE, new_state)
+        })
+}
+```
+
+When working with lifecycle event handlers, the `HandlerContext` provides utility functions for accessing and mutating the state of a lane. Above, we build up a combinator that gets the state of the lane and then returns an effect which mutates it.
+
+# Client
+
+We can reuse most of the work that we did in the previous agent tutorial and then add a new downlink for sending commands to our `exec` lane - we'll need to copy over our `Operation` enumeration too.
+
+For our new `exec` downlink, we can add it as follows:
+
+```rust
+let exec_downlink = handle
+    .value_downlink::<Operation>(exec_path)
+    .downlink_config(DownlinkConfig::default())
+    .open()
+    .await
+    .expect("Failed to open exec downlink");
+```
+
+To issue our command envelopes, we invoke the `set` function on the downlink:
+
+```rust
+exec_downlink.set(Operation::Add(1000)).await.unwrap();
+exec_downlink.set(Operation::Sub(13)).await.unwrap();
+```
+
+# Running
+
+Run the server and client applications as we did in the previous agent tutorial.
+
+In our client terminal, we will see the following output:
+
+```
+Downlink linked
+Downlink synced with: 0
+Downlink event: 1000
+Downlink event: 987
+```
+
+# Full code
+
+The full code for this page is available at: [todo-link](todo-link).
diff --git a/src/_rust_devguide/index.md b/src/_rust_devguide/index.md
new file mode 100644
index 0000000..bf4ae67
--- /dev/null
+++ b/src/_rust_devguide/index.md
@@ -0,0 +1,11 @@
+---
+title: Developer Guide
+permalink: /rust/developer-guide/
+layout: documentation
+description: "Developer Guide to SwimOS"
+toc: false
+---
+
+This ordered guide will introduce you step by step to SwimOS, starting with the fundamentals and working up to some more advanced features.
+
+{% include docs-listing.html %}
diff --git a/src/_tutorials/demos.md b/src/_rust_tutorials/demos.md
similarity index 100%
rename from src/_tutorials/demos.md
rename to src/_rust_tutorials/demos.md
diff --git a/src/_rust_tutorials/index.md b/src/_rust_tutorials/index.md
new file mode 100644
index 0000000..2eb1673
--- /dev/null
+++ b/src/_rust_tutorials/index.md
@@ -0,0 +1,15 @@
+---
+title: Tutorials
+layout: documentation
+toc: false
+permalink: /rust/tutorials/
+redirect_from:
+  - /rust/tutorials/
+description: "Building streaming data applications doesn't have to be hard. Learn how to use SwimOS's stateful back-end & real time front-end to bring your data to life."
+---
+
+These tutorials will walk you through creating a SwimOS project from start to finish.
+
+{% include tutorials.html %}
+
+{% include docs-listing.html %}
diff --git a/src/_rust_tutorials/monitor.md b/src/_rust_tutorials/monitor.md
new file mode 100644
index 0000000..b85e20b
--- /dev/null
+++ b/src/_rust_tutorials/monitor.md
@@ -0,0 +1,280 @@
+---
+title: Process Monitor Tutorial
+description:
+group: Tutorials
+layout: documentation
+---
+
+## Overview
+
+We’ll be looking at a process monitoring <a href="https://github.com/swimos/tutorial-monitor" target="_blank">example</a> that provides data for individual machines in a cluster, as well as aggregate metrics for the cluster. The solution will consist of two separate applications. The first is a client application that runs on each machine in the cluster to collect monitoring information. The second is a SwimOS server application that processes results for each machine via a `MachineAgent`, and then aggregates cluster-level metrics across all machines via a `ClusterAgent`.
+
+## Monitoring Client
+
+The Monitoring Client relies on the <a href="https://www.oshi.ooo/" target="_blank">OSHI</a> java library to extract system information from each host machine in the cluster. OSHI is a free JNA-based (native) Operating system and Hardware Information library for Java. Each client periodically reports its operational health to the server. Since the server runs on top of the SwimOS runtime, the monitoring client uses `swim.client.ClientRuntime` to send commands bearing monitoring data updates.
+
+### Monitor
+
+Though we are going to keep our example concise, we’ll still include some forward-thinking design so that you can quickly extend the example. We’ve defined an abstract base class called <a href="https://github.com/swimos/tutorial-monitor/blob/main/server/src/main/java/swim/monitor/client/Monitor.java" target="_blank">`Monitor`</a> that defines a `monitor()` method to initiate monitoring, along with the two methods it invokes: `sleep()`, which is implemented, and `pulse()` which will be overridden for each monitor to respond as it needs for each interval.
+
+Since `Monitor` must send data to Web Agents, it maintains a `WarpRef` along with URI path info for host, node, and lane. `Monitor` also maintains an OSHI `SystemInformation` object to perform monitoring on the host as well as a configurable `pulseInterval`.
+
+### ProcessMonitor
+
+We have a single override of `Monitor` in our example, with <a href="https://github.com/swimos/tutorial-monitor/blob/main/server/src/main/java/swim/monitor/client/ProcessMonitor.java" target="_blank">`ProcessMonitor`</a>, though upon perusal, you might notice it includes usage information that really belongs in a separate monitor. We’ll just look at the usage information.
+
+```java
+  @Override
+  public void pulse() {
+    Value usage = getUsage(timestamp);
+    this.warpRef.command(hostUri, nodeUri, Uri.parse("addUsage"), usage);
+  }
+
+  private Value getMemoryUtilization() {
+    return Record.create(6)
+      .slot("total", systemInfo.getHardware().getMemory().getTotal())
+      .slot("available", systemInfo.getHardware().getMemory().getAvailable());
+  }
+
+  private Value getHardwareUtilization() {
+    Value memoryInfo = getMemoryUtilization();
+    return Record.of().slot("memory", memoryInfo);
+  }
+
+  private Value getUsage(final long timestamp) {
+    Value hardwareInfo = getHardwareUtilization();
+
+    return Record.of()
+            .slot("timestamp", timestamp)
+            .slot("hardware", hardwareInfo);
+  }
+```
+
+### SwimMonitorClient
+
+In <a href="https://github.com/swimos/tutorial-monitor/blob/main/server/src/main/java/swim/monitor/client/SwimMonitorClient.java" target="_blank">`SwimMonitorClient`</a>, we will instantiate the SwimOS client runtime, the OSHI `SystemInfo`, which then starts the `ProcessMonitor` to feed data to the server".
+
+```java
+  public static final String HOST = System.getProperty("host", "warp://localhost:9001");
+  public static final Uri HOST_URI = Uri.parse(HOST);
+
+  public static void main(String[] args) {
+    final ClientRuntime swimClient = new ClientRuntime();
+    swimClient.start();
+    final SystemInfo systemInfo = new SystemInfo();
+    startProcessMonitor(swimClient, systemInfo);
+  }
+
+  private static void startProcessMonitor(final ClientRuntime swimClient, final SystemInfo systemInfo) {
+    final ProcessMonitor processMonitor = new ProcessMonitor(swimClient, HOST_URI, systemInfo);
+    swimClient.stage().execute(() -> {
+      System.out.println("Starting ProcessMonitor");
+      processMonitor.monitor();
+    });
+  }
+```
+
+## Monitoring Server
+
+### Machine Web Agent
+
+The information collected for monitoring can be broken into three categories:
+
+- system information for each machine (static)
+- usage information for each machine (dynamic)
+- process information for each process running on the machine (static and dynamic)
+
+When static information is set, the <a href="https://github.com/swimos/tutorial-monitor/blob/main/server/src/main/java/swim/monitor/agent/MachineAgent.java" target="_blank">`MachineAgent`</a> registers with the cluster using the following command:
+
+```java
+command(CLUSTER_URI_PATTERN.apply("default"), ADD_MACHINE_CLUSTER_LANE_URI, Uri.form().mold(nodeUri()).toValue());
+```
+
+Once machine agents register, the `ClusterAgent` can observe the direct streaming of their state changes.
+For instance, when `addUsage()` is invoked, the `usage` lane receives a new value, and in response to that, the status is set
+with the help of `StatusComputer.computeStatusFromUsage()`.
+
+```java
+  @SwimLane("addUsage")
+  CommandLane<Value> addUsage = this.<Value>commandLane()
+          .onCommand(v -> this.usage.set(v));
+
+  @SwimLane("usage")
+  ValueLane<Value> usage = this.<Value>valueLane()
+          .didSet((newValue, oldValue) -> {
+            this.status.set(StatusComputer.computeStatusFromUsage(this.status.get(), newValue));
+          });
+
+  @SwimLane("status")
+  ValueLane<Value> status = this.<Value>valueLane()
+          .willSet(StatusComputer::computeSeverityFromStatus)
+          .didSet((newValue, oldValue) -> {
+            final long timestamp = newValue.get("timestamp").longValue(0L);
+            if (timestamp > 0L) {
+              this.statusHistory.put(timestamp, newValue.removed("timestamp"));
+            }
+          });
+```
+
+Let's look how memory usage information is computed at the machine level using `StatusComputer.computeStatusFromUsage()`.
+
+```java
+  public static Value computeStatusFromUsage(Value currentStatus, final Value usage) {
+    final Value memory = usage.get("hardware").get("memory");
+    final long available = memory.get("available").longValue(0);
+    final long total = memory.get("total").longValue(0);
+    final float memoryUsage = 1.0f - (total == 0L ? 0.0f : (float) available / (float) total);
+    return currentStatus.updated("memory_usage", memoryUsage);
+}
+```
+
+### Cluster Web Agent
+
+The <a href="https://github.com/swimos/tutorial-monitor/blob/main/server/src/main/java/swim/monitor/agent/ClusterAgent.java" target="_blank">`ClusterAgent`</a> receives monitoring data for all machines that register to it via a corresponding `MachineAgent`. When a machine registers using `ClusterAgent::addMachine` command lane, the `ClusterAgent` downlinks to the `MachineAgent`’s status lane via its `machines` `JoinValueLane`:
+
+```java
+  @SwimLane("addMachine")
+  CommandLane<Value> addMachine = this.<Value>commandLane()
+          .onCommand(v ->
+                  this.machines.downlink(v)
+                          .nodeUri(Uri.form().cast(v))
+                          .laneUri(STATUS_MACHINE_LANE_URI)
+                          .open());
+
+  @SwimLane("machines")
+  JoinValueLane<Value, Value> machines = this.<Value, Value>joinValueLane()
+          .didUpdate((key, newValue, oldValue) -> {
+            computeStatus();
+
+            if (newValue.get("disconnected").isDefined()) {
+              this.machines.remove(key);
+            }
+          });
+```
+
+For an explanation of downlinking, see [`downlinks`]({% link _java_backend/downlinks.md %}).
+The `machines` join value lane exposes the status of individual machines with respect to system information, usage information, and process information, so that any connected client can check detail status for any machine in the cluster.
+
+`ClusterAgent` also aggregates the status of all machines and reflects that in an aggregate status to reflect the health of the cluster. The status is exposed to interested clients through the `status` value lane, and history is stored for the last 200 values. Note that since `timestamp` is the key, the field is removed from the corresponding value:
+
+```java
+  @SwimLane("status")
+  ValueLane<Value> status = this.<Value>valueLane()
+          .didSet((newValue, oldValue) -> {
+            final long timestamp = newValue.get("timestamp").longValue(0L);
+            if (timestamp > 0L) {
+              this.statusHistory.put(timestamp, newValue.removed("timestamp"));
+            }
+          });
+```
+
+`ClusterAgent` has a `computeStatus()` method that updates the aggregate status as machine status updates stream in. We will cherry picks portions of `computeStatus()` that generate the aggregate value for memory usage:
+
+```java
+    double clusterAvgMemoryUsage = 0.0;
+    double clusterAvgMemoryUsage = 0.0;
+
+    float totalMemoryUsage = 0.0f, maxMemoryUsage = 0.0f;
+    int memoryCount = 0;
+
+    final Set<Value> keys = this.machines.keySet();
+    for (Value key : keys) {
+      final Value machineStatus = this.machines.get(key);
+
+      if (machineStatus.get("memory_usage").isDefined()) {
+        memoryCount++;
+        float memoryUsage = machineStatus.get("memory_usage").floatValue(0.0f);
+        totalMemoryUsage += memoryUsage;
+        if (memoryUsage > maxMemoryUsage) {
+          maxMemoryUsage = memoryUsage;
+        }
+      }
+
+    final float avgMemoryUsage = memoryCount == 0 ? 0 : totalMemoryUsage / memoryCount;
+
+    this.status.set(
+            this.status.get()
+                    .updated("average_memory_usage", avgMemoryUsage)
+                    .updated("max_memory_usage", maxMemoryUsage)
+    );
+```
+
+## Rendering Status Information
+
+Data can be rendered to an HTML page relatively simply. To illustrate that, we include an html file <a href="https://github.com/swimos/tutorial-monitor/blob/main/ui/index.html" target="_blank">`/ui/index.html`</a> that illustrates how this is done. Most of this is boilerplate for displaying a chart, but the application-specific bit is here:
+
+```java
+const histogramLink = swim.downlinkMap()
+    .hostUri("warp://localhost:9001")
+    .nodeUri("/cluster/default")
+    .laneUri("statusHistory")
+    .didUpdate(function(key, value) {
+      addToPlot(key, value);
+    })
+    .didRemove(function(key) {
+      removeFromPlot(key);
+    })
+    .open();
+```
+
+## Running the Tutorial
+
+### Running the Server
+
+```bash
+$ ./gradlew run
+```
+
+### Running a Client
+
+```bash
+$ ./gradlew -Dhost=<warp-address-of-server> runClient
+```
+
+Example:
+
+```bash
+$ ./gradlew -Dhost=warp://localhost:9001 runClient
+```
+
+## Streaming APIs
+
+### Introspection APIs
+
+#### Stream High level stats
+
+```
+swim-cli sync -h warp://localhost:9001 -n swim:meta:mesh -l pulse
+```
+
+### Application APIs
+
+#### Streaming APIs for top level Monitor
+
+```
+swim-cli sync -h warp://localhost:9001 -n /monitor -l machines
+swim-cli sync -h warp://localhost:9001 -n /monitor -l clusters
+```
+
+#### Streaming APIs for a given Machine
+
+```
+swim-cli sync -h warp://localhost:9001 -n /machine/my-machine -l status
+swim-cli sync -h warp://localhost:9001 -n /machine/my-machine -l statusHistory
+swim-cli sync -h warp://localhost:9001 -n /machine/my-machine -l systemInfo
+swim-cli sync -h warp://localhost:9001 -n /machine/my-machine -l usage
+swim-cli sync -h warp://localhost:9001 -n /machine/my-machine -l processes
+swim-cli sync -h warp://localhost:9001 -n /machine/my-machine -l sessions
+```
+
+#### Streaming APIs for a Cluster
+
+```
+swim-cli sync -h warp://localhost:9001 -n /cluster/abc -l machines
+swim-cli sync -h warp://localhost:9001 -n /cluster/abc -l status
+swim-cli sync -h warp://localhost:9001 -n /cluster/abc -l statusHistory
+```
+
+## Running the UI
+
+Now, you can view the UI by appending "/ui" to the host address using the HTTP or HTTPS protocol, such as http://localhost:9001/ui.
diff --git a/src/_rust_tutorials/transit.md b/src/_rust_tutorials/transit.md
new file mode 100644
index 0000000..fe255b0
--- /dev/null
+++ b/src/_rust_tutorials/transit.md
@@ -0,0 +1,576 @@
+---
+title: Transit Tutorial
+description: 
+group: Tutorials
+layout: documentation
+---
+
+# Application Overview
+
+The Transit Tutorial walks you step-by-step through creating a small, but fully functional end-to-end, streaming data application for conveying real-time city transit information. We will retrieve live transit information via UmoIQ's <a href="https://retro.umoiq.com/" target="_blank">NextBus API</a> for 6 Southern California transportation agencies.
+
+At a high level, the flow looks like this:
+
+1.  We load agencies from CSV file to create an Agency Web Agent
+2. This triggers a poller for acessing REST APIs for each Agency Agent
+3. The REST API response is then used to update the AgencyAgent
+4. The AgencyAgent update triggers messages to the Vehicle Agent
+
+Then we will process this information to maintain location, speed, and acceleration information for each of the agency's vehicles. The goal of this application is to demonstrate how to connect to a REST API and create a streaming API for each entity/domain object (here, Agency and Vehicle). The Streaming APIs can be consumed by third-party applications, whether browser-based applications using SwimOS's real-time map UI or standalone applications using the typescript client APIs.
+
+# Stateful Entity Model
+
+## How to Model Web Agents from Entities
+We determine our entities in the same way we would if doing object oriented design, data modeling, or domain driven-design. We start at a conceptual level that partitions information with respect to distinct, immutable identities that encapsulate a common behavior for state that changes over time. In our case, the UmoIQ API allows callers to obtain live vehicle information based on agency. That essentially determines our entities that will be represented as Web Agents: `AgencyAgent` and `VehicleAgent`.
+
+### Modeling the `AgencyAgent`
+
+#### Specifying the Agency Web Agent
+We will define our `AgencyAgent` by extending SwimOS's `AbstractAgent` that gives us an extensive range of capabilities with the convenience of inversion of control so we simply extend and override to express application specific details:
+
+```java
+public class AgencyAgent extends AbstractAgent {
+  private static final Logger log = Logger.getLogger(AgencyAgent.class.getName());
+
+    @Override
+    public void didStart() {
+        log.info(() -> String.format("Starting Agent:%s", nodeUri()));
+    }
+}
+```
+
+#### Defining the Agency data structure
+
+We will be using a <a href="https://github.com/swimos/tutorial-transit/blob/main/server/src/main/resources/agencies.csv" target="_blank">csv file</a> to specify 6 Southern California agencies:
+
+```
+west-hollywood,S-CA,US
+glendale,S-CA,US
+glendale-beeline,S-CA,US
+omnitrans,S-CA,US
+pvpta,S-CA,US
+ucla,S-CA,US
+```
+
+Each Agency record provides an id, a state (or in the case of California, Southern and Northern California), and the country. Though tag is essential, the others provide human readability, so we can add those to our Agency entity model and define our Web Agent:
+{id:jhu-apl,state:MD,country:US,index:0}
+
+```java
+Value data = Record.of()
+  .slot("id", "glendale")
+  .slog("state", "S-CA")
+  .slot("country", "US")
+```
+
+#### Defining an Agency `ValueLane`
+We can define a the equivalent of a member variable on the Web Agent called info and take action upon update:
+
+```java
+@SwimLane("info")
+public ValueLane<Value> info = this.<Value>valueLane()
+    .didSet((newValue, oldValue) -> {
+      // take action
+  });
+```
+
+We can update state within our Web Agent like this:
+
+```java
+this.info.set(data);
+```
+
+#### Defining an Agency `CommandLane`
+We can provide an end-point to update it externally through a command like this:
+
+```java
+
+@SwimLane("addInfo")
+public CommandLane<Value> addInfo = this.<Value>commandLane()
+  .onCommand(this::onInfo);
+
+private void onInfo(Value agency) {
+  Value oldValue = info.get();
+  info.set(agency);
+}
+```
+
+#### Storing Agency vehicles in a `MapLane``
+Since the purpose of the transit API is to retrieve vehicle information that must be retrieved with respect to Agency tag, we will also want to maintain a collection of vehicles. Let's map them by vehicle id:
+
+```java
+    @SwimLane("vehicles")
+    public MapLane<String, Value> vehicles;
+```
+
+Great, now let's get to the Vehicle entity and its corresponding Web Agent representation.
+
+### Modeling the `VehicleAgent`
+Now that we have some Agency tags to work with, we are in a position to retrieve live data for an Agency's vehicles. We can using the following API for this: 
+
+https://retro.umoiq.com/service/publicXMLFeed?command=vehicleLocations&a=ccrta&t=0
+
+```xml
+<body 
+  copyright="All data copyright APL 2023."
+>
+  <vehicle
+    id="2"
+    routeTag="internal"
+    dirTag="loop"
+    lat="39.170158"
+    lon="-76.895701"
+    secsSinceReport="4"
+    predictable="true"
+    heading="262"
+    speedKmHr="0"
+  />
+  <vehicle
+    id="9"
+    routeTag="marc"
+    dirTag="loop"
+    lat="39.160668"
+    lon="-76.897818"
+    secsSinceReport="8"
+    predictable="true"
+    heading="276"
+    speedKmHr="56"
+  />
+<lastTime time="1691616124147"/>
+</body></body>
+```
+
+#### Specifying the Vehicle Web Agent
+As with `AgencyAgent`, we will define our `VehicleAgent` by extending SwimOS's `AbstractAgent`:
+
+```java
+public class VehicleAgent extends AbstractAgent {
+  private static final Logger log = Logger.getLogger(VehicleAgent.class.getName());
+  private long lastReportedTime = 0L;
+
+    @Override
+    public void didStart() {
+    log.info(()-> String.format("Started Agent: %s", nodeUri()));
+    }
+}
+```
+
+#### Defining the Vehicle data structure
+We can directly translate this to SwimOS data format:
+
+```java
+Value data = Record.of()
+  .slot("id", "9")
+  .slot("dirTag", "loop")
+  .slot("lat", 39.160668)
+  .slot("lon", -76.897818)
+  .slot("secsSinceReport", 8)
+  .slot("predictable", true)
+  .slot("heading", "276")
+  .slot("speedKmHr", 56);
+```
+
+#### Defining a Vehicle ValueLane
+As before, we can specify a `ValueLane` on the Web Agent to represent this state:
+
+```java
+  @SwimLane("vehicle")
+  public ValueLane<Value> vehicle = this.<Value>valueLane()
+          .didSet((newValue, oldValue) -> {
+            // take action
+          });
+```
+
+We can add whatever lanes we need to manage our processing needs. In this case, we want to maintain a list of the last 10 speeds and derive the last 10 accelerations.
+
+```java
+  @SwimLane("speeds")
+  public MapLane<Long, Integer> speeds;
+
+  @SwimLane("accelerations")
+  public MapLane<Long, Integer> accelerations;
+```
+
+#### Defining a Vehicle CommandLane
+`CommandLane`s are used by clients and other Web Agents to send notifications and trigger processing. 
+
+```java
+
+  @SwimLane("updateVehicle")
+  public CommandLane<Value> updateVehicle = this.<Value>commandLane().onCommand(this::onUpdateVehicle);
+
+  private void onUpdateVehicle(Value v) {
+    final Value oldState = vehicle.get();
+    final long time = System.currentTimeMillis() - (v.get("secsSinceReport").longValue(0) * 1000L);
+    final int oldSpeed = oldState.isDefined() ? oldState.get("speed").intValue(0) : 0;
+    final int newSpeed = v.get("speed").intValue(0);
+
+    this.vehicle.set(v);
+    this.speeds.put(time, newSpeed);
+    if (this.speeds.size() > 10) {
+      this.speeds.drop(speeds.size() - 10);
+    }
+    if (lastReportedTime > 0) {
+      final float acceleration = (float) ((newSpeed - oldSpeed)) / (time - this.lastReportedTime) * 3600;
+      this.accelerations.put(time, Math.round(acceleration));
+      if (this.accelerations.size() > 10) {
+        this.accelerations.drop(accelerations.size() - 10);
+      }
+    }
+    this.lastReportedTime = time;
+  }
+```
+
+# Connect to Data Source
+
+## Consuming data from a web API
+Let's start by connecting to UmoIQ's live transit API. As you saw, the data format is XML. We'll be using `java.net.http.HttpClient`, which requires Java 11. If you are using an older version of Java, you can use `java.net.HttpUrlConnection` instead as shown <a href="https://github.com/swimos/tutorial-transit/blob/main/server/src/main/java/swim/transit/NextBusHttpAPI.java" target="_blank">here</a>.
+
+This requires a wee bit of boilerplate, as shown below:
+
+```java
+    private static HttpRequest requestForEndpoint(String endpoint) {
+        return HttpRequest.newBuilder(URI.create(endpoint))
+                .GET()
+                .headers("Accept-Encoding", "gzip")
+                .build();
+    }
+```
+
+With that in hand, we can invoke it when loading Agency agents as shown below. The key mechanism we use to go from XML to SwimOS's internal data format is `swim.xml.Xml`, which exposes `Xml.structureParser().documentParser()``.
+
+```java
+    public static Value getVehiclesForAgency(HttpClient executor, String agency, long since) {
+        final HttpRequest request = requestForEndpoint(endpointForAgency(agency, since));
+        try {
+            final HttpResponse<InputStream> response = executor.send(request,
+                    HttpResponse.BodyHandlers.ofInputStream());
+            return Utf8.read(new GZIPInputStream(response.body()), Xml.structureParser().documentParser());
+            // Alternatively: convert GZIPInputStream to String, then invoke the more
+            // familiar Xml.parse()
+        } catch (Exception e) {
+            e.printStackTrace();
+            return Value.absent();
+        }
+    }
+```
+
+# Send to Data to Web Agents
+
+## Converting at rest data to streaming data
+Because we are not working with a naturally streaming data source like Kafka or Pulsar, the only instance in which we'll need to poll is upon ingestion. Fortunately SwimOS has timer and task facilities we can make use of. Here are the declarations:
+
+```java
+private TimerRef timer;
+private final TaskRef agencyPollTask = ...
+```
+
+To start polling, we'll define `initPoll()` to execute the TaskRef's cue() method:
+
+```java
+    private void initPoll() {
+        this.timer = setTimer((long) (Math.random() * 1000), () -> {
+          this.agencyPollTask.cue();
+          this.timer.reschedule(15000L);
+        });
+      }```
+
+Now, we just need the TaskRef definition:
+
+```java
+    private final TaskRef agencyPollTask = asyncStage().task(new AbstractTask() {
+  
+      private long lastTime = 0L; // This will update via API responses
+  
+      @Override
+      public void runTask() {
+        final String aid = agencyId();
+        // Make API call
+        final Value payload = NextBusHttpAPI.getVehiclesForAgency(Assets.httpClient(), aid, this.lastTime);
+        // Extract information for all vehicles and the payload's timestamp
+        //final List<Value> vehicleInfos = new ArrayList<>(payload.length());
+        final Record vehicleInfos = Record.of();
+        for (Item i : payload) {
+          if (i.head() instanceof Attr) {
+            final String label = i.head().key().stringValue(null);
+            if ("vehicle".equals(label)) {
+                final Value vehicle = i.head().toValue();
+                final String vehicleUri = "/vehicle/" + aid + "/" + vehicle.get("id").stringValue();
+                final Value vehicleInfo = vehicle.updatedSlot("uri", vehicleUri);
+                vehicleInfos.add(vehicleInfo);
+            } else if ("lastTime".equals(label)) {
+              this.lastTime = i.head().toValue().get("time").longValue();
+            }
+          }
+        }
+        onVehicles(vehicleInfos);
+      }
+  
+      @Override
+      public boolean taskWillBlock() {
+        return true;
+      }
+  
+    });
+```
+
+
+## Feeding Web Agents
+
+Web Agents are URI addressable. We send them data via commands and create downlinks to receive data from them. You'll recall the `addInfo` `CommandLane` from earlier. We can invoke these end-points using SwimOS's warp protocol using a `WarpRef` and passing in the URL, the `ComandLane`'s name, and any input, typically a value object, but sometimes Java primitives like String and Integer that will seamlessly get converted to and from `Value` objects.
+
+```java
+warp.command(agencyUri, "addInfo", someValue);
+```
+
+We will load static `AgencyAgent` data via our CSV file. Let's define a `loadAgencies()` method for this. Most of this is boilerplate Java. The `SwimOS` specific part involves creating a `Record` object, `agencies`, to represent a list of objects, as well as an additional `Record` object to represent the fields of each agent element. In addition to the static data from the CSV, we derive an `index` field.
+
+```
+  private static Value loadAgencies() {
+    Record agencies = Record.of();
+    InputStream is = null;
+    Scanner scanner = null;
+    try {
+      is = TransitPlane.class.getResourceAsStream("/agencies.csv");
+      scanner = new Scanner(is, "UTF-8");
+      int index = 0;
+      while (scanner.hasNextLine()) {
+        final String[] line = scanner.nextLine().split(",");
+        if (line.length >= 3) {
+          Value newAgency = Record.of().slot("id", line[0]).slot("state", line[1]).slot("country", line[2]).slot("index", index++);
+          agencies.item(newAgency);
+        }
+      }
+    } catch (Throwable t) {
+      log.severe(()->String.format("Exception thrown\n%s", t));
+    } finally {
+      try {
+        if (is != null) {
+          is.close();
+        }
+      } catch (IOException ignore) {
+      }
+      if (scanner != null) {
+        scanner.close();
+      }
+    }
+    return agencies;
+  }
+```
+
+## Materializing Web Agents
+To make use of the SwimOS runtime, we will define our application entry-point by extending `AbstractPlane`. We are calling our application space, "transit." We will create a server to activate the SwimOS runtime and associate our application space with it. After starting the runtime, we can use the `Space` object as a `WarpRef` to interact with Web Agents using SwimOS's WARP protocol based on Websockets supercharged with multicast, multiplexing and delta encoding.
+
+As this is the entry point of our application, it is a logical place to initialize static data. Here we will invoke a method to start `AgencyAgents`:
+
+```java
+public class TransitPlane extends AbstractPlane {
+  public static void main(String[] args) {
+    final Kernel kernel = ServerLoader.loadServer();
+    final Space space = kernel.getSpace("transit");
+    kernel.start();
+    log.info("Running TransitPlane...");
+    startAgencies(space);
+    kernel.run(); // blocks until termination
+  }
+}
+```
+
+Starting an agent is accomplished by simply sending a message to a known Web Agent type. We can do that by sending a command to a lane. It isn't even important if the lane exists or not. Since we are initializing state, it makes sense to invoke the `AgencyAgent`'s `addInfo` command.
+
+```java
+  private static void startAgencies(WarpRef warp) {
+    final Value agencies = loadAgencies();
+    for (Item agency : agencies) {
+      log.info(Recon.toString(agency));
+      String agencyUri = "/agency/" +
+              agency.get("id").stringValue();
+      warp.command(agencyUri, "addInfo", agency.toValue());
+    }
+    try {
+      Thread.sleep(3000);
+    } catch (InterruptedException e) {
+
+    }
+  }
+```
+
+We now have to define our application space in order to access the SwimOS runtime and make use of Web Agents. We will register our `TransitPlane` and our two Web Agents, `AgencyAgent` and `VehicleAgent` by creating a configuration file using SwimOS's JSON-like Recon format.
+
+```
+transit: @fabric {
+    @plane(class: "swim.transit.TransitPlane")
+    @node {
+        pattern: "/agency/:id"
+        @agent(class: "swim.transit.agent.AgencyAgent")
+    }
+    @node {
+        pattern: "/vehicle/:agency/:id"
+        @agent(class: "swim.transit.agent.VehicleAgent")
+    }
+}
+
+@web(port: 9001) {
+  space: "transit"
+  @websocket {
+    serverCompressionLevel: 0# -1 = default; 0 = off; 1-9 = deflate level
+    clientCompressionLevel: 0# -1 = default; 0 = off; 1-9 = deflate level
+  }
+}
+```
+
+The source can be found <a href="https://github.com/swimos/tutorial-transit/blob/main/server/src/main/resources/server.recon" target="_blank">here</a>.
+
+# Continuously Evaluate Business Logic in Web Agents
+
+`ValueLane`, `MapLane`, and `CommandLane` provide a wide range of callback mechanisms for implementing business logic in response to streaming data. We will just utilize those for responding to incoming data. 
+
+## Executing Agency logic
+
+As seen previously, the `AgencyAgent`'s identification data will be stored in the `info` `ValueLane`, which will be populated using the `addInfo` `CommandLane`. We'll maintain a count of vehicles via the `vehicleCount` `ValueLane` to compute averages, and store that average in the `avgVehicleSpeed` `ValueLane`.
+
+Our primary method for processing streaming data for the `AgencyAgent` will be through `agencyPollTask.runTask()` which invokes `onVehicles()`.
+
+```java
+@SwimLane("count")
+public ValueLane<Integer> vehicleCount;
+
+@SwimLane("speed")
+public ValueLane<Float> avgVehicleSpeed;
+
+@SwimLane("addInfo")
+public CommandLane<Value> addInfo = this.<Value>commandLane()
+  .onCommand(this::onInfo);
+
+@SwimLane("info")
+public ValueLane<Value> info = this.<Value>valueLane()
+  .didSet((n, o) -> {
+    abortPoll();
+    startPoll(n);
+  });
+```
+
+ As we poll the UmoIQ live transit API, we'll publish the results by invoking `onVehicles`. First we'll iterate over the new vehicles and remove any that are no longer active:
+
+ ```java
+private void onVehicles(Value newVehicles) {
+  Map<String, Value> vehicleUpdates = new HashMap<>();
+
+  for (Item v : newVehicles) {
+    vehicleUpdates.put(v.get("uri").stringValue(), v.toValue());
+  }
+
+  updateVehicles(vehicleUpdates);
+
+  // skipping other details
+}
+
+private void updateVehicles(Map<String, Value> newVehicles) {
+  final Collection<Value> currentVehicles = this.vehicles.values();
+
+  for (Value vehicle : currentVehicles) {
+    if (!newVehicles.containsKey(vehicle.get("uri").stringValue())) {
+      vehicles.remove(vehicle.get("uri").stringValue());
+    }
+  }
+}
+```
+
+We'll compute the average vehicle speed with some trivial logic, as well as send updated state to each of the agency's `VehicleAgent`s using the `context` variable provided by `AbstractAgent` as a `WarpRef`.
+
+```java
+int speedSum = 0;
+
+for (Value v : vehicleUpdates.values()) {
+  final String vehicleUri = v.get("uri").stringValue();
+
+  if (vehicleUri != null && !vehicleUri.equals("")) {
+    context.command(vehicleUri, "updateVehicle", v.toValue());
+    addVehicle(vehicleUri, v);
+    speedSum += v.get("speed").intValue();
+  }
+}
+
+vehicleCount.set(this.vehicles.size());
+
+if (vehicleCount.get() > 0) {
+  avgVehicleSpeed.set(((float) speedSum) / vehicleCount.get());
+}
+```
+
+# Tutorial application source code
+
+Source code for the demo application can be found here:
+
+<a href="https://github.com/swimos/tutorial-transit/blob/main/server" target="_blank">https://github.com/swimos/tutorial-transit/blob/main/server</a>
+
+You can run `./gradlew run` from the server directory to run the backend. For a visual representation, see the next section.
+
+# Real-time Map UI which Uses the Streaming API from the Web Agents
+
+While it is reassuring to have console output of arriving data, a visual representation is much more impactful and compelling. There is a simple HTML page provided in this tutorial's repository that you can open to see a visualization of buses moving along their routes on top of the map. The HTML page connects to an agency's URI, streams the vehicle locations, and plots it on a map. To change agencies, you simply change the agency tag in the `nodeUri`, e.g. "glendale":
+
+```typescript
+const vehiclesLink = warp.downlinkMap({
+  hostUri: "warp://localhost:9001",
+  nodeUri: "/agency/glendale",
+  laneUri: "vehicles",
+```
+
+Here's the HTML source:
+
+<a href="https://github.com/swimos/tutorial-transit/blob/main/ui/index.html" target="_blank">https://github.com/swimos/tutorial-transit/blob/main/ui/index.html</a>
+
+By including a few SwimOS libraries, the HTML made includes a tiny bit of JavaScript to reference the host, the Web Agent uri, and the specific lane. Through calls to `swim.HTMLView`, `swim.MapboxView`, and `swim.GeoTreeView`, the incoming, real-time data stream from SwimOS gets plotted directly against the map.
+
+You can find directions in the top-level <a href="https://github.com/swimos/tutorial-transit/blob/main/README.md" target="_blank">README.md</a> file to run the UI.
+
+# Observing state changes via `swim-cli`
+
+The SwimOS platform provides a CLI tool, <a href="https://www.swimos.org/guides/cli.html" target="_blank">`swim-cli`</a> that makes it simple to stream data from Web Agents. It can be installed globally as follows: 
+
+```
+npm install -g @swim/cli
+```
+
+## Streaming `AgencyAgent`` data to the command line
+Let's try retrieving values for the glendale agency (make sure the swim application is running from the server directory via `./gradlew run`):
+
+```
+swim-cli link -h warp://localhost:9001 -n /agency/glendale -l vehicles 
+```
+
+Here is some sample output, your results will vary, naturally. Note three vehicles drop off the list of vehicles and have been removed, while the next three vehicles have received updates:
+
+```
+@remove(key:"/vehicle/glendale/B73")
+@remove(key:"/vehicle/glendale/B75")
+@remove(key:"/vehicle/glendale/B79")
+@update(key:"/vehicle/glendale/B98"){id:glendale,uri:"/vehicle/glendale/B98",agency:glendale,dirId:SBrivpac,latitude:34.14249,longitude:-118.26002,speed:28,secsSinceReport:9,heading:"90"}
+@update(key:"/vehicle/glendale/B99"){id:glendale,uri:"/vehicle/glendale/B99",agency:glendale,dirId:"2britc_d",latitude:34.1261,longitude:-118.25915,speed:38,secsSinceReport:4,heading:"55"}
+@update(key:"/vehicle/glendale/B67"){id:glendale,uri:"/vehicle/glendale/B67",agency:glendale,dirId:gga,latitude:34.133774,longitude:-118.24615,speed:36,secsSinceReport:2,heading:"91"}
+```
+
+As with the web page, simple change the `nodeUri` to view data from a different agency:
+
+```
+swim-cli link -h warp://localhost:9001 -n /agency/west-hollywood -l vehicles 
+```
+
+```
+@update(key:"/vehicle/west-hollywood/116"){id:west-hollywood,uri:"/vehicle/west-hollywood/116",agency:west-hollywood,dirId:CLWB_1_var0,latitude:34.08677,longitude:-118.37749,speed:32,secsSinceReport:15,heading:"6"}
+```
+
+## Streaming VehicleAgent data to the command line
+
+To stream data to a `VehicleAgent`, you can use the following command below. You can switch out the agency id and vehicle id for the `nodeUri`. Examples can be seen from the `AgencyAgent` output.
+
+``````
+swim-cli link -h warp://localhost:9001 -n /vehicle/west-hollywood/116 -l vehicle
+```
+
+which yields:
+
+```
+{id:"116",routeTag:CLEB,dirTag:CLEB_0_var0,lat:"34.083697",lon:"-118.387662",secsSinceReport:"6",predictable:true,heading:"322",speedKmHr:"11",uri:"/vehicle/west-hollywood/116"}
+{id:"116",routeTag:CLEB,dirTag:CLEB_0_var0,lat:"34.084492",lon:"-118.386684",secsSinceReport:"8",predictable:true,heading:"51",speedKmHr:"32",uri:"/vehicle/west-hollywood/116"}
+```