diff --git a/01-RESEARCH/019-a-warm-twin-of-the-running-mesh/00-overview.md b/01-RESEARCH/019-a-warm-twin-of-the-running-mesh/00-overview.md
new file mode 100644
index 0000000..8d993c7
--- /dev/null
+++ b/01-RESEARCH/019-a-warm-twin-of-the-running-mesh/00-overview.md
@@ -0,0 +1,55 @@
+---
+status: active
+initiated: 2026-10-02
+touches: [lab, the lab module, the catalogue, assignments, settings, the controller's store]
+became: []
+---
+
+# 019 — A warm twin of the running mesh
+
+## What is being investigated
+
+Whether the lab can keep a **warm twin of the mesh as it actually runs**: the same machines, carrying
+the same catalogue, the same assignments and the same settings as the live mesh, raised once and kept
+ready, so that a change can be tested against the mesh as it is rather than against a scenario
+written to resemble it. A run against the twin would go through the lab module like any other run:
+a branch per repository, the twin restored from its snapshot, the change applied, the beds run.
+
+## Why
+
+The lab's beds raise meshes from declarations written for the bed. They prove the mechanism. They
+do not prove that a change works on the mesh that runs, with its accumulated assignments, its
+operator settings, its adopted machines and its modules in their real combinations. The gap showed
+on 2026-10-02:
+
+- a change to how a module's settings reach its files was correct in every bed, and would have put a
+  setting into the container runtime's configuration on every machine running that module. Only the
+  composed plan for a real machine showed it;
+- a firewall change composed cleanly and still left one machine's wired port unfiltered, because
+  of a link that machine had and no bed did;
+- a recovery step was needed on every machine at once, after a change that every bed had passed.
+
+The lab already has a warm mode, a snapshot of a raised scenario restored between attempts. What it
+does not have is a scenario that **is** the running mesh, kept current with it.
+
+## What it touches
+
+- **What a twin is made of.** The catalogue and the assignments are records; settings are records;
+  secrets are sealed to machines and cannot be copied. Which of these can be carried to the lab as
+  they are, which must be substituted, and how a twin says what it substituted.
+- **Data.** A twin with the real catalogue and no real data proves composition and delivery, not a
+  migration. Whether a twin carries data, a sample of it, or none.
+- **Keeping it current.** A twin raised once goes stale with the first merge. Whether it is
+  re-derived from the live records on each run, refreshed on a schedule, or rebuilt only when asked.
+- **Machines.** The live mesh has machines of different kinds: a server on the internet, machines
+  behind a home router, a laptop that sleeps. Which of their properties a twin must reproduce for a
+  test to mean anything (reachability, the private network, the found firewall).
+- **Cost.** The lab machine's memory and disk, and how long a twin takes to raise from cold.
+- **The lab module's tools.** A run against the twin rather than a named bed: one more tool, or an
+  argument to the run tool.
+
+## Starting point
+
+The lab module (ADR 0172) runs beds through the mesh, and the lab's warm mode already snapshots and
+restores a raised scenario. The beds that raise a machine shaped like one live machine from the
+catalogue are the nearest existing thing, and the first to compare against.