diff --git a/FABRIC-2.md b/FABRIC-2.md
index c8253b7..7344bb6 100644
--- a/FABRIC-2.md
+++ b/FABRIC-2.md
@@ -2902,3 +2902,67 @@ flag, QEMU monitor socket exposure, install path.
 at all, even in QEMU: the USB stack itself (area B).** Every other gap in areas A, C, D, and H
 either directly requires it or becomes untestable without it. This is the honest first-cut
 recommendation if a concrete next milestone gets picked from this analysis.
+
+---
+
+## W. Artemis concept board — consolidated vision, one place, 2026-08-22
+
+Sections U and V are the detailed working log (every requirement in the order it came up,
+then the gap check against the code). This section is the single consolidated picture pulled
+from both, requested explicitly so the whole shape exists in one place rather than only as a
+trail of addenda. **Still direction, not a spec — nothing here is implemented.**
+
+**The vision, in one paragraph.** Two physical identities, each minted onto its own USB thumb
+drive via Ed25519 PKI (Captain Bob as operator, `zuse` as superuser) — the same drives double
+as both credential and portable storage. Insert a drive, and the system authenticates that
+identity, spins up (or re-attaches) that identity's own VM, and binds a generic, shared
+console to that VM alone via a key/lock match. That identity's data lives across a
+transparent, bidirectional migration between the main SSD and the drive itself — the drive
+carries its own map of what's theirs, so the SSD needs no central per-user directory, and
+block ownership is derived from identity rather than from insertion order, so it's identical
+every time regardless of which drive got plugged in first that session. Everything the system
+loads — the kernel's own trust root down through every capsule — is signed and verified
+against a certificate embedded in the kernel image, chained to a CA that never itself gets
+embedded or loaded. A foreign or unrecognized drive gets refused with a warning, not silently
+overwritten; the zuse credential, once minted, can never be re-minted.
+
+**The components, each pointing at its detailed treatment:**
+
+| Component | Detail | Status (Section V) |
+|---|---|---|
+| Block address space + device chain | U items 1-2 | ✅ exists |
+| Identity-derived block ranges | U item 3 | ❌ not started |
+| Drive-carried block map | U item 4 | ❌ not started |
+| Bidirectional migration state machine | U item 5 | ❌ not started (trigger hook ready) |
+| Foreign-drive protection | U item 7 | ❌ not started (magic-number precedent exists) |
+| Zuse one-way burn | U item 8 | ❌ credential unbuilt (ratchet mechanism exists) |
+| Console/VM key-match binding | U item 9 | ❌ not started (VM spin-up call exists) |
+| Kernel/capsule PKI signing chain | U items 10-14 | ❌ not started (manifest anchor + blob embedding exist) |
+| Contributor capsule directory/trust tiers | U items 15-18 | ❌ not started, explicitly sequenced last |
+| USB hardware (xHCI + MSC r/w driver) | Gap analysis area B | ❌ zero code, the hard prerequisite |
+| Capsule distribution server (Nexus-style) | later conversation | ❌ concept only |
+| Live-boot ISO ("try it") | area H | ✅ exists and works today |
+| Install path ("install it") | area H | ❌ not started, explicitly deferred — "not that risky yet" |
+| QEMU monitor socket (dev iteration) | area B | ❌ one-line gap, not blocking |
+
+**Sequencing, as currently stated across the whole conversation, nearest-term first:**
+
+1. **Bare-metal boot from a physical USB stick, demo/"try it" mode only — the actual next
+   milestone**, confirmed this session as *not* gated on the USB-hardware-driver gap above.
+   Booting *from* USB is a UEFI firmware responsibility, not a kernel one — the same
+   `starkernel.iso` (amd64/aarch64, El Torito) or raw disk image (riscv64) already rebuilt on
+   every QEMU launch this session is, mechanically, the artifact to `dd` onto a physical drive.
+   Two 64GB SanDisk drives are on hand and available right now for this; one currently carries
+   a Kubuntu 26.04-era live ISO, re-flashable without loss (re-downloadable). Real-hardware
+   UEFI firmware varies from QEMU's OVMF, so the first real boot is a genuine test, not a
+   formality — noted, not treated as a blocker.
+2. Everything in this section's component table below the live-boot-ISO row — the actual
+   home-blocks/thumbdrive-as-persistent-identity-storage subsystem — waits on the USB
+   hardware driver (area B), which is the honest, singular hard prerequisite once milestone 1
+   is done.
+3. Contributor capsules/trust tiers, explicitly sequenced after the ACL/PKI work closes.
+4. Networking (capsule distribution server, WiFi), explicitly sequenced after that.
+
+Not started: no code, no capsule work, no hardware testing yet. This section exists so a
+future session (or Captain Bob re-reading cold) gets the whole shape in one read, rather than
+needing to reconstruct it by reading U, V, and this section's own cross-references in sequence.